My Way ©MJH 1996-2018; Index

Modified May 19, 2018 3:59 pm

Customizing TMG™
Custom Tag Type Descriptions My Way ©MJH

Chapter Contents

Tag Groups, Tag Types, and Tags

Groups: Name, Birth, Relationship, Marriage, Divorce, Death, Burial, History, Address, Other
Types
Tags

Tag Attributes

Type, Primary, Memo, Sentence, Citation, Principals, Dates, Place, Witnesses

My Tag Type Customizations: Names, Colors

Customizations to record Adoption

Approaches: One Dataset Person, Two Dataset Persons
Tag Types for Recording Adoption Events

Relationship Tag Types

Standard: *-Ado, *-Ste, *-Oth
Custom: *-Bio2, *-Can, *-Nil

Name Tag Types

Name Tag Styles: AllFields, Census, Location, Married, OneName, Repository, Source, SurnamePreSort
Name Tag marked Primary, Inferred Name Parts
Indexes and Exclusion: TMG People (Name) Index, Second-Site Name Index

Name-Adopted, Name-Assume, Name-Baptism, Name-Birth, Name-Chg, Name-Comm, Name-Index, Name-Link-Only, Name-Loc-Var, Name-Marr (Name-Marr, Name-Married, Name-Marr-Title, Name-Maiden), Name-Nick, Name-One, Name-Step, Name-SurnameSort, Name-Title, Name-Var

Custom Tag Type Name Suffixes

*Alt, *Assume, *Date, *Find, *Img, *Loc, *Narr, *Nil, *Sens, *Sum, *Text

Alphabetical List of Custom Event Tag Type Descriptions: 1

Address, Adoption/AdoptOrig , Adoptee, AdopteeFind, AdoptGive, AdoptGiveFind, Adopting, AdoptingFind, AdoptLink, Anecdote, AnecdoteSens, Associatn, Author, BaptAdult, BaptFind, Baptism, BaptNil, Birth, BirthAssume, BirthFind, BirthIlleg, BirthMultiple, BirthNil, BirthOrder, BirthPar, BirthRec, BirthStill, Burial, Cem-list-head, Census Tags, ChildFind, Christning, Codicil, Conflict, Correspondence, Created, Cremation, Death, DeathAssume, DeathAssumeBur, DeathAssumeCrem, DeathFind, DeathNil, Descriptn, Dissolved, Divorce, Divorce Fl, DivorceAssume, DivorceFind, Duplicate, DupNil, Education, EmigFind, Emigration, Employment, Event-Misc, FamilySectionNote, Graduation , Guardian, GuardianFind, Illness, ImmigFind, Immigratn, JournalConclusion, JournalIntro, LocationLink, Marr Assume, Marr Bann, Marr Cont, Marr Dummy, Marr Find, Marr Lic, Marr Never, Marr Nil, Marr Not, Marriage, Milit-Beg, Milit-End, MilService, Misc, MiscFind, MiscNil, MovedFrom, MovedTo, MoveFind, NarrativeChildren, Natlzation, Note, Num Child, Num Marr, Obituary, Occupation, Ordained, Ordination, Probate, PsgrList, Related, RelateFind, Research, ResidedAddress, ResideFind, Residence/ResideOrig , Sex Change, Src Link, TestTag, Title-Event, Transcript, Twin, Widow(er), Will

Tag Groups, Tag Types, and Tags

TMG defines the following ten tag groups which governs the intended purpose of a tag in each group regardless of its tag type. My custom tag sentences chapter contains a list of all tag types within these tag groups, including my custom tag types.

Name

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.

Birth

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

Relationship

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.

Marriage

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 date 3 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

Divorce

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.

Death

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.

Burial

A tag whose type is in this group documents any events that may be associated with the disposition of the body of one or two 6 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.

History

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

Address

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

Other

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

Tag Attributes

Type

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

Primary designation

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

Memo

A leading ‘!’ as the first thing in a memo implies 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 codes (‘-’ or ‘--’) are also honored. Memo text can be split into nine separately referencable 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.

Sentence

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.

Citation

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.

Principal 1&2

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

Date & Sort Date

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.

Place

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.

Witnesses

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

My Tag Type Customizations

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 Type Names

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 characters for a tag type name. 13 As 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 deactivate 14 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, 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 types 15 , 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 constains sensitive date 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 .

Custom Tag Type Colors

Beginning with Version 8 I use the Tag Label Color feature to set various tag types with specific font/background color settings. These colors are defined on the General Tab of the Tag Type Description. If you set a color TMG will prompt you to enable this option in Preferences/Project/Colors. (See also the colors associated with People Accents and Filters.)

Birth, BirthStill, Burial, Cremation, Death, Marriage tag types

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)

All *Find tag types, plus Note and Misc tag types

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)

All Census* tag types plus the Src Link tag type

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.

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

I often use the Transcript tag 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)

Relationship *-Bio plus BirthPar tag types

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 a Bio relationship 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)

Relationship *-Ado plus Adopt* tag types and Name-Adopted and Name-Birth

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)

TestTag type

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)

Adoption

Since I am adopted, and there are other adoptions in my various lines, I have given the issue of entering information about adoption and its events and consequences considerable thought. While TMG is primarily designed to track genetic relationships, and therefore to only record the relationship between the birth parents and their child, many users find the need to record either the adoptive family relationship as it may be the only one known, as well as the desire to record both family relationships if known. Adoption presents not only the problem of multiple sets of parents (of which only one set can be Primary in TMG for the purposes of lineage and to appear and produce linkages on certain ancestor and descendant reports), but also probably a name change (with only one name able to be Primary and appear on many reports). Finally some societies and individuals find the facts about an adoption sensitive. This issue requires careful consideration of how to customize TMG to record non-genetic relationships which it is not fully designed to record.

Two Approaches to Recording Adoption Data

Due to certain fixed characteristics of how TMG produces various reports, there has arisen two different “camps” on data entry of adoption information, each with its entry and report output advantages and disadvantages: the one dataset “person” approach versus the two dataset “persons” approach. 16 Second Site has since added several features not part of TMG which expand the options for reporting on non-biological children, but only for that output format.

Some philosophically insist that there is only one “real” person, who has one lifetime of events and possibly different names and familial relationships during that one lifetime. They are opposed to splitting this information into two dataset “persons”, however well these two “persons” may be cross-referenced and linked. Some base this position on their view that genealogy tracks biological entities and relationships, so only one “person” and one set of biological parents is ever appropriate to record.

In contrast, others find that the sensitivity of this event imposes a need for separation of data before and after the adoption, and desire the ability to produce reports that simultaneously show both parental relationships, and/or hide the very existence of information before or after the event. They want the program be able to produce reports that not only show biological lineage, but also be able to show surname lineage.

The single standard Adoption event tag type provided by TMG is adequate for simply recording this fact/event about a person. But based on recurring comments, many users find this one event tag insufficient to deal with the multiple events that can occur as part of this action, to record the consequences of this complicating life activity, and to output the various information about this activity.

The one person approach is designed to focus on only one lineage, usually the biological lineage. It often makes it harder for the offspring to trace their adoptive surname lineage, but facilitates viewing the relationship with the adopting parents as simply an event in the biological child’s life. Since Second Site can optionally output non-Primary parent relationships, the adoptive parents can be more easily identified in that output simply by the existence of the relationship tag. Further, customizing information in the Family Sections by using the NarrativeChildren tag can produce lists of non-Primary adopted children in the Family sections of the parent’s TMG Journal report and in the parent’s Second Site Person page.

The two person approach intends to focus “equally” on both lineages, but by its nature links the person’s offspring to the adopted lineage which is their surname. It often makes it harder for the offspring to trace back to their biological lineage, but facilitates viewing the events in the life of the adopted “person” as “beginning” with adoption and connected to the adopted lineage. It also makes it harder to trace forward from the biological ancestors to the offspring of the adopted person, but facilitates viewing the events in the life of the birth “person” and this line as “ending” with adoption. An extreme example of the two person approach would involve two separate datasets, one for each “person” and lineage, where each dataset really contains a one person approach. As in the true one-person approach, Second Site’s options to output non-Primary parent relationships as well as both programs ability to use the NarrativeChildren tag to custom output a list of adopted children in the Family Sections can also help with this approach.

While one could design custom event tag types tailored to one or the other of these specific approaches, I have designed custom tag types which I believe can be used in documenting this complex event and its relationships whichever approach one may decide to use. These custom tag types can even be consistently used in the same dataset when some persons are entered using one approach and some using the other, and can even facilitate changing a person in the dataset from one approach to the other should that be desired. Regardless of the approach used, since much of this data can be sensitive, exclusion markers (or sensitivity brackets/braces) are probably required in a number of sentences, and some of these adoption specific tag types may want to be excluded from output on some reports.

One Dataset Person Adoption Recording Approach

If only one “person” is entered in the dataset and has all the information, then they can be assigned both Name-Birth and Name-Adopted Name-Var tags to the same person, and be linked to all known sets of parents with the appropriate relationship suffixes of “ *-bio ” or “ *-ado ” to this same person. To record being given up for adoption the person would select the Name-Birth variation in an AdoptGive event tag with Witness role adoptee linked to the “ *-bio ” parents as Principals if known, or the Adoptee tag with Principal role Ward if they are unknown. The adoption details would be recorded selecting the Name-Adopted variation in the Adopting event tag with Witness role adoptee linked to the “ *-ado ” parents as Principals if known, or in a separate Adoptee tag with Principal role Adoptee if they are unknown. By using Name-Adopted with the Adopting and NarrativeChildren tags customized to list adopted children, only the adopted name appears in the adoptive parents’ narrative, which may be appropriate for sensitivity reasons.

If a new birth certificate is filed with the new name, this event can be documented with my custom BirthRec tag type (in the Other group, not in the Birth group) and using the name from the Name-Adopted tag. Finally, the child is linked to both sets of parents with the appropriate relationship tag types (usually “ *-Biological/*-Bio ” and “ *-Adopted/*-Ado ”), with those tags for the appropriate parents (typically biological) marked Primary. However, 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, the “other” set of parents will be included in the Second Site child’s list of parents. In all cases one should set this one person’s standard ADOPTED Flag to the value ‘Y’.

Either Name-Var or set of parents can be selected as Primary on these tags to reflect the preferred lineage focus, but that forces manually switching them every time report outputs want to focus on the “other” lineage. Further if you want whomever are now the non-Primary parents to also list such a child you will have to switch the Principals on the custom NarrativeChildren tag being used to produce that output. And all must be switched back to some “preferred” setting after producing that report. As this one person can have tags for both names and for both sets of parents, this lineage switch may only require changing their Primary designation, one keystroke per those tags. And since NarrativeChildren tags only output for the parents if Primary, you could define NarrativeChildren tags for both sets of parents where you also could simple change whether the tag was Primary for one set and not Primary for the other set of parents. If only some of these custom Adoption event tags for this person are desired to not print, they may have to have their tag types changed to equivalent “sensitive” tag types or modified sentences or roles as described above. While that lineage focus switch may also be only a tag type menu choice for each tag, it could be quite a chore depending upon the number of adoptees in the dataset whose focus need to switch. Setting a Focus Group based on the ADOPTED Flag would aid in this task. Depending upon the desired lineage focus of the reports, which Name-Var used for multiple tags may have to be changed, especially for the Birth tag, although if the tags simply use the Primary name, then changing which Name-Var is Primary will accomplish the change.

Those who have used this one person approach often describe generating two tag types for some events, like a custom BirthAdopted tag type to duplicate the standard Birth , etc., to aid in producing output for the two cases by selecting appropriate tag types. Whichever parents are chosen as Primary, realize that on some of the “other” parents’ reports the person may not even show as a child, much less show a relationship between these other parents and the offspring of this person. Obviously that will affect any lineage reports as the ancestry from the offspring will show only through the Primary parents. I use a NarrativeChildren or equivalent tag which can add a list of non-Primary adopted children within a replacement header of an automatically generated Primary children list for either program. As described with that tag type, the sentence output of the tag can only be used to include a list of non-Primary children as part of the heading of this tag if the tag will appear for these parent(s). Even without using such a tag, the relationship of the person to the non-Primary parents would still be indicated in the narratives if any of these adoption related event tags linked to them are printed. Most people who use this approach prefer to only focus on one lineage for a particular person, usually the biological line and the birth parents, and normally just leave the focus parents Primary for all reports thereby obscuring the “other” lineage, often not even entering that other lineage in the database. If both lineages are actually entered into the dataset, even if one is intended to be obscured, then the two person approach is more often used.

Two Dataset Persons Adoption Recording Approach

One can enter two separate “persons” in the dataset, a “birth” person to record events before the adoption and an “adopted” person to record events after the adoption. Some linkage between these two dataset “persons” is usually appropriate. If both “persons” are linked to both sets of parents with the appropriate relationship suffixes of “ -bio ” or “ -ado ”, this will ensure that each set of parents will reflect a child, as well as providing some linkage from either parents to either “person”. However some reports may reflect both sets of parents as having “two” children, these two “persons”. Normally people use this two person approach to avoid dual linkages, and would not link either “person” to the “other” set of parents.

Using a custom AdoptLink tag type in the Other group as part of the two person approach makes the linkage clear, and allows changing the Person View to the other dataset “person” a simple click on that name in this tag. By using this AdoptLink tag type while linking each “person” to only one parental relationship allows the linkage between the two dataset “persons” to remain clear.

Although this two person approach allows reports for both sets of parents to always reflect a (single) child for this person, there is still the issue of reports involving the lineage of the offspring of the adoptee. As the offspring are typically linked to the “adopted” person because of the surname, their “biological” lineage is then not shown. My custom use of a NarrativeChildren tag to insert a list of non-Primary adopted children in a heading of a Family section is not appropriate in this case since for both sets of parents the child is Primary, so will automatically be listed in a Family section. With the two person approach I feel the AdoptLink tag is sufficient. Switching the offspring from one parent “person” to the other is very difficult, especially as each person usually does not have all the life events recorded in the other person. For example, the “birth” person probably does not have the marriage tag for the offspring, and the “adopted” person usually needs some special Birth tag with source citations that are not the actual birth records. Most people who use this two person approach have no intentions of linking the events following adoption to the “birth” person and their ancestry, and just leave the offspring connected to the “adopted” person, with all that implies. Flags can be used to exclude “birth” persons from appearing in reports as often their birth itself is sensitive. For example, a choice will have to be made as to which of the two persons get their ADOPTED flag set to ‘Y’ for the purpose of excluding such persons from reports, or whether to set that value for both.

The “birth” person should be “ -bio ” linked to the birth parents, and should have a Birth tag citing documentation using the birth name, such as the original birth certificate. Next, the “birth” person would likely have an AdoptGive event tag with Witness role adoptee linked to the “ -bio ” parents as Principals if known, or an Adoptee tag with Principal role Ward . Alternatively in the case of being orphaned, they could be a witness on the Death tag of the parent, with an appropriate witness sentence and memo. The “birth” and “adopted” persons would be linked by my custom AdoptLink event tag. The adoption details would not be recorded in the “birth” person but in the Adopting event tag with the “adopted” person. Any events between being given up for adoption and being adopted, such as time spent in a children’s home, would be recorded with the “birth” person. If no second “adopted” person is entered but an adoption is known to occur, a separate Adoptee tag could be entered with Principal role Adoptee . Normally any events after the adoption would not be recorded with the “birth” person but with the “adopted” person.

The “adopted” person would have an “ *-ado ” relationship link to the adopting parents and would probably have some custom Birth tag, such as the BirthIlleg tag type, citing documentation from the adoption records for the birth data. If the adoption is truly trying to be hidden, the technically false relationship of “ -bio ” could still be used, but some documentation with exclusion or sensitivity marking or a separate explanation in an excluded tag type should be included. If details of prior release of parental rights is known to have occurred, an initial Adoptee tag could be entered for the “adopted” person with Principal role Ward , if no second “birth” person is entered in the dataset where this documentation would normally be recorded. Next the “adopted” person would have an Adopting tag with Witness role adoptee linked to the adopting parents as Principals if known, or a second Adoptee tag with Principal role Adoptee if the adopting parents are not entered in the dataset. If both “birth” and “adopted” persons are entered they would be linked by my custom AdoptLink event tag. Normally no events prior to the adoption are recorded with the “adopted” person, but all events subsequent to the adoption are recorded with this “adopted” person.

Tag Types for Recording Adoption Events

While I do not use the deactivated standard tag type Adoption , the tag types I use for recording adoptions are described below. Note that if the data of some adoptions is desired to remain sensitive, but some adoptions to be able to appear in reports, having all tags for all people of the same tag type does not facilitate this. One could copy the definition of any of these custom tag types to one with the same name but adding a trailing suffix (e.g. my ‘Sens’ for sensitive, or perhaps ‘NP’ for not print) to the tag type name, to facilitate separately selecting such sensitive tags and excluding them from reports. One could also modify some of the sentences with exclusion or sensitivity markers and/or add roles that limited what printed.

*-Adopted(*-Ado) relationship tag type creates a link between the adopted child and one adopting parent, typically set as a non-Primary relationship tag. Second Site has an option to display these non-Primary relationships on the child’s page.

 

Adoptee for a child known to be adopted but with little known data.
Similar to the standard Adoption tag type, this tag type has the child as the Principal but does not link to any parents. I use it for either of the two adoption events when those parents are unknown.

 

AdoptGive for the first of the adoption events, when parents give up children for adoption.

Adopting for the second of the adoption events, when parents adopt children.
These two main tag types for these adoption events have the parents as Principals and the child(ren) as Witness(es). The disadvantage of these tags having the child as a Witness is that the “Show witnessed events” 17 display option is required to see these adoption events in the child’s Person View. As I always have that display preference set, it is not an issue for me. Having these two separate tags, AdoptGive and Adopting , allows for the typical passage of time between these two events, which may even occur in separate locations. Further it decouples the two events, as the children may be adopted as a result of being orphaned rather than due to a release of parental rights.

 

AdopteeFind when only the fact that the child was adopted is known

AdoptGiveFind when only the fact that the parents gave up children for adoption is known

AdoptingFind when only the fact that parents had adopted children is known
All of these *Find tag types can easily be converted to their respective event tag type when the documentation is found.

 

BirthRec for recording a new legal birth record using the adopted name

 

Name-Adopted and Name-Birth to select the appropriate name for a person’s event tag
The Name-Adopted should have a Sort Date after the adoption event tag for the child’s narrative.

 

AdoptLink to link the two persons when using the two dataset person approach

 

NarrativeChildren is a special tag type which can be used to list children with non-Primary *-Ado relationship tags to this Subject. This tag type is designed to hijact and replace the heading of a parent’s automatic Family section of Primary children in a TMG Journal report, and the heading of a parent’s automatic Family Section of Primary children in a Second Site Person page. By default non-Primary children are not automatically output in these Family sections by either software. However, a non-standard usage of this tag can manually insert a list of non-Primary adopted children in the replacement header. Such a list could be caused to output in a Family section even if symmetric equivalent non-Primary *-Ado relationship tags are not entered for this parent/child, although I try to maintain that symmetry. TMG (and optionally Second Site) automatically controls where the text of this tag will output, whether it will output in these reports, and which Family section heading will be replaced. This tag type only gives the user control of what text, such as a list of adopted non-Primary children, will replace the automatic heading. For complete details of this tag type see its full description.

This tag type can provide symmetry to the Second Site option to list non-Primary adopting parents on a child’s page automatically identified from non-Primary *-Ado relationship tags. A NarrativeChildren tag can be used to list non-Primary adopted children on a parent’s page even if symmetric equivalent non-Primary *-Ado relationship tags are not entered. I suggest, and try to ensure, that if non-Primary *-Ado parents are linked and listed, then companion custom NarrativeChildren tags are used to produce non-Primary lists of adopted children, and vice versa.

As mentioned in the full description of this tag type, whether this tag type can output the list of non-Primary adopted children in a Family section heading depends mainly on whether an automatically generated Family section would be output for the specific Principal(s) who are assigned to this tag. A Family section is only output automatically by either software if there are children linked as Primary parents only to the sole Principal or to both of the two Principals of this tag, or there is a tag in the Marriage group with its one or two Principals exactly matching the one or two Principals of this tag. If a Family section will not be automatically generated by the above conditions, then a “dummy” Family section must be caused in order to output the list. This can be done by using the Marr Dummy tag type 18 with Principal(s) exactly matching the Principal(s) of this NarrativeChildren tag. If the Family section will include a list of Primary children, the normal heading text for that list of children to follow also must be included in this tag’s custom sentence template.

I defined two custom roles with special codes 19 in their sentence templates for linking the adopting parent(s) as Principal(s) to this tag type: Adoptor(s) and Adoptor(s)Alone. The Principals assigned to this NarrativeChildren tag will be either the one parent who adopts, or the couple who adopts together. If only one person adopts all these children then they are the sole Principal on this tag, if both adopt this list of non-Primary children then they should both linked as Principals. Which role to use depends on whether the Principal(s) who adopt have Primary children. If the sole Principal has one-Parent Primary children, or the two Principals have shared two-parent Primary children, use the role Adoptor(s) for the one or for both to also produce the “Children of” heading for those children. Otherwise use the role Adoptor(s)Alone for the sole Principal or both Principals which will not include that heading. The role Adoptor(s) can be used when there are no Primary children if the heading of an empty list is desired for the Principal(s). This may be desired for a couple to make it clear there are no Primary children.

If a Family section with matching Principal(s) to this tag’s Principal(s) does not exist to be hijacked (because there are neither Primary children nor a tag in the Marriage group for this tag’s Principal(s)), then a dummy matching Principal(s) Family section needs to be forced to exist with a dummy Marr_Dummy tag as described above.

I defined nine childN roles to link non-Primary adopted children as Witnesses to the adopting parent and separately identify each in their separate split Memo part.. At least one adopted child, usually using the child1 role, must be identified in split memo part [M1] for the sentence templates to work properly. Subsequent childN roles and split memo parts are optional. Generally they should be linked using their birth Name-Birth variation (their name prior to adoption) if this is not sensitive. Otherwise they can be linked using their Name-Adopted variation so that only their adopted name appears in the adoptive parents’ narrative. These Witness roles can be used in each child’s split memo part to output their name and also to produce IDs or hyperlinks. Do not include carriage returns beginning or ending each split memo part as the list will then be double spaced.

I also created three special heading Witness roles of bioParent, bioMrs , and bioMr to name one or both Primary (biological) parents in the heading produced by this tag’s sentence template. If this information is not sensitive this can be useful since commonly all biological parents for a list are the same. Otherwise one of the generic Witness roles of parents1, parents2, parents3, etc. can be used for one or both biological parents to output within that childN matching split memo text rather than in the heading if desired. Typically only one such person needs to be linked and identified if a biological parent remarries and the new spouse is the adoptor of the children. While identifying either or both birth parents may be sensitive, these Witness roles can be used, if desired, to identify birth parents (usually only the mother) whether or not related to the adopting parent(s).

For further explanations of these Principal and Witness roles and which should be used when, see the description of the NarrativeChildren tag type and the section explaining manually inserting a list of non-Primary children using this tag type.

Relationship Tag Types

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

Standard Relationship Tag Types

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.

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 Tag Sentences chapter.

Custom Relationship Tag Types

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

Instead I prefer to use an appropriate memo in my custom Related tag type.

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 Tag Sentences chapter.

*-Bio2 MJH , *-Bio3 MJH

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

*-Can MJH

I define *-Can as a full set of relationship tag types 21 for “candidate” or potential parent/child relationships. This is when I think a pair of people might be parent/child, but am very uncertain. 22 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.

*-Nil MJH

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

Name Tag Types

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. 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 an event tag, the name of the “other” Principal shown for a 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 person in the output of that tag.

Name Tag Styles

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 style labels OneNameG and OneNameS as a reminder the text should be the same). Entering the name in this manner will define it so that name variables and indexes in both TMG and Second Site will handle it appropriately. (Note the trailing comma in the Surname display template which is required as described further in the Data Entry chapter concerning Name Styles.)

“OneName” Name Style Templates

GivenName [OneNameG]

The complete one name (duplicate in both fields)

Surname [OneNameS]

The complete one name (duplicate in both fields)

Output

[OneNameS]

Surname sort

[SortSurname]

Surname display

[OneNameS],

Given sort

[SortGiven]

Given display

[OneNameG]

Children/Siblings

[OneNameS]

Name Tag marked Primary

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.

Inferred Name Parts

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 sentences 23 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. 24 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 and surname both non-empty, display as expected

• given empty and surname non-empty, display with given copied from Primary

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

• given name non-empty and surname empty, surname copied from Primary.

Name Tags—Indexes and Exclusion

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.

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:

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

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

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

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.

TMG People (Name) index

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]> ” which provides a non-empty sentence template even if output of excluded data is selected. 25 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.

Second Site Name Index

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

• whether that Name tag’s sentence is excluded.

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 current Version 6.3 Build 00. 26

As specified 27 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 This 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 bugs 28 associated with both single and double sentence exclusion of non-Primary Name tags. Version 6.2 Build 11 resolved 29 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:

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

• not output the Name tag sentence, but include the variation 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. 30 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.

Name-Assume MJH

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.

Name-Baptm/Name-Baptism

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.

Name-Birth MJH , Name-Adopted MJH

See the discussion of all custom tag types I have defined for the events of Adoption above. 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.

Name-Chg/Name-Change

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). 31 See also Sex Change below. Use the memo to explain.

Name-Comm MJH , Name-Marr-Comm

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.

Name-Find

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.

Name-Index MJH , Name-Std, Name-Standard

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 excluded 32 , 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. 33 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.

Name-Loc-Var MJH

I am experimenting 34 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. 35

Name-Marr/Name-Married MJH , Name-Marr-Title MJH , Name-Maiden

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 added later using the TMG Utility) and will only have the surname entered. Selecting a name using this standard Name-Var tag allows sentence constructs 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 and the Name-Married name is selected for the wife as P2. (See also the 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. 36

There are multiple suggestions to enter a maiden surname in the suffix field of a Name-Married tag, either with the exclusion character 37 -(née Maiden-surname) ”, or using sensitivity brackets, 38 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 text 39 (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 cusom 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. 40 Thus I generally select my custom Name-Marr-Title tag type to be included in reports and indexes. I do not select the standard Name-Married tag type to be included 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]) . 41 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 like: Male: “ <[P]|[P1F]><| and [P2]> ” and Female: “ <[P]|[P2F]><| and [P1]> ”. Or alternatively to use the maiden surname: Male: “ <[P]|[P1F]><| and [P2] (née [P2L])> ” and Female: “ <[P]|[P2F] (née [P2L])><| and [P1]> ”. 42 For example if the tag has two Principals entered P1:male and P2:female, and you desire the woman’s title and maiden surname to output but the Subject listed first, these sentence variables output the subject’s name first as respectively: “Jacob and Mrs. Elizabeth Sark (née Bowers)” and “Elizabeth (née Bowers) and Jacob Sark”.

One “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 contains the 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 later find I need one or more of these three fields (e.g. PreSurname) and add these back in to the templates, but currently 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, must enter it and the Surname.

OtherName [Married]

The husband’s surname (possibly with a PreSurname) 43

Output

[Mrs.] [GivenName] [Married]

Surname sort

[Married], [SortGiven] [Maiden]

Surname display

[Married], [GivenName], [Mrs.] (née [Maiden])

Given sort

[SortGiven]    44 [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.

Reminders

Name-Marr-Title

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)”

Name-Nick MJH

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.

Name-One MJH , Name-Link-Only MJH

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

Name-Step, Name-Foster

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 sensitive data. I do not currently use this method.

Name-Surname-Sort MJH

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 excluded 46 , 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]

Name-Title, Title-Event

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

Name-Var/Name-Variation MJH

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:

[PP] [M1] [N] <[M2]>

with [M1] as “surname is often spelled” followed by::

[+] [M1] [N] <[M2]>

with [M1] as “or less often as”.

Custom Tag Type Suffixes

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.

*Alt

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.

*Assume MJH

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 suggestion 48 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

*Date, *Loc

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.

*Find MJH

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.

*Img

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.

*Nil MJH

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

*Sens MJH

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. My only current example is the general purpose AnecdoteSens 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 do not do so.

*Sum, *Narr, *Text

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.

Custom Tag Types

Address MJH

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

Adoption/AdoptOrig

I choose to rename the standard Adoption tag type with it default sentences as AdoptOrig and deactivate it to avoid confusion with tags used in other people’s databases. This standard tag type is designed to have the child as the Principal. That design of this single tag type does not provide the flexibility or document the event and its the relationships as I desire them. However my similar custom tag type Adoptee can be used for circumstances when a child is known to be adopted but much of the data, including the parents, is unknown.

Adoptee MJH

In the cases where either or both sets of parents are not in the dataset, but either the events of giving up for adoption or the adoption itself are known to have occurred, this single custom tag type with its sentences and my typical split memo can be used for either or both events. In these cases of incomplete data, the child is the Principal using either the role Ward to reflect being given up for adoption by unknown parents and becoming a ward, or Adoptee to record being adopted by unknown parents. While no parents are known or linked to this tag, others can be linked using the standard Witness role.

AdoptGive MJH

This custom tag type documents the first of the two possible adoption actions: disconnection from the birth parents. The companion Adopting custom tag type documents the second action: connection to the adopting parents.

Each child would be a Witness using the role child where the birth parents are the Principals using the roles BirthMother and BirthFather . The tag sentences should give details of the release of parental rights, with any sources cited to the tag such as court records. This tag type uses a similar basic split memo structure and sentences as Adopting . [M1] provides general adoption details for output in the parent(s) narrative. As information about the two birth parents may be different, [M4] can be an optional comment output only for the BirthMother, and [M5] an optional comment only for the BirthFather. [M2] is an optional comment that will preceed the date, and [M3] an optional comment that will preceed the location. Each child’s witness sentence uses both the [M2] and [M3] adoption details as wells as its own optional [WM] . This allows a single AdoptGive tag to be used when multiple children are given up for adoption at the same time, and even allows for linking others using the standard Witness role with their separate witness memos to this release of parental rights.

Adopting MJH

This custom tag type and its sentences is to document the second of the two possible adoption actions: connection to adopting parents when they take on parental status. (See also the similar tag Guardian when persons take on guardianship of children without adoption.) The companion AdoptGive custom tag type documents the first action: disconnection from the birth parents.

Each child would be a Witness using the same role adoptee where any adopting parent is a Principal using the role Adoptor . The tag sentences should give details of the Adoptor(s) being granted parental status, with any sources cited to the tag such as court records. The sentences will work whether only one person is doing the adopting (e.g. a spouse of a birth parent) or two people. This tag type uses a similar basic split memo structure and sentences as AdoptGive. [M1] provides general adopting details for output in the Adoptor(s) narrative. [M2] is an optional comment that will preceed the date, and [M3] an optional comment that will preceed the location. [M4] can be used to provide a qualifier to the adoptee’s name(s), such as “his infant nephew” or “his wife’s children from her first marriage”. Each child’s sentence uses both the [M2] and [M3] adopting details as well as its own optional [WM] . This also allows a single Adopting tag to be used when multiple children are adopted 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 adoption event.

AdoptLink MJH

If I choose the two dataset persons approach to recording this person’s adoption, I use this custom tag type in the Other group to make a link between these two entries, with the two “persons” as the two Principals using roles BirthName and AdoptedName . Its sentences are designed to specify the “other” name used either before or after the Adoption in both persons narratives. [M1] is an optional memo for the BirthName role sentence, and [M2] a separate optional memo for the AdoptedName role sentence.

AdopteeFind MJH , AdoptGiveFind MJH , AdoptingFind MJH

Companion research tag types using my *Find structure have also been defined for searching for documentation about the adoption events: AdopteeFind with its sentences when you only know the child was adopted but nothing else, AdoptGiveFind with its sentences when you know parent(s) gave up a child but no further details, and AdoptingFind with its sentences when you know parent(s) adopted a child but no further details. In all these *Find tags [M1] allows a comment about where to look. As of Version 8 I use a common color highlight for all Find tag types. The subsequent memo parts are in the same order as their equivalent main tag types so that [M1] can simply be deleted when the tag type is changed to the main type. The Witness roles source and repository are also defined to link to the appropriate pseudo people.

Anecdote MJH , AnecdoteSens MJH

I use this standard tag type for general purpose data about the person when there is no specific tag type for that purpose. Its sentences consist simply of the Memo fields for complete flexibility. The separate AnecdoteSens tag type is identical but exists for sensitive information, and I seldom select this tag type to print.

Associatn/Association MJH

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

Author MJH (or Me)

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.

BaptAdult MJH

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 adoption in both the Principal(s) and Witness sentences. [M2] is an optional comment for the Principal(s), [WM] for each Witness.

BaptFind MJH

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.

Baptism MJH

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.

BaptNil MJH

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.

Birth MJH

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.) I added [PAR] to the standard 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 [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 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 example, if the memo only contains the ASCII Tab character followed by the split memo separator codes ‘||’, it will be considered empty. 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.) If the sentence contains the <[M]> (or <[M1]> ) conditional memo variable, this tag with no (other) printable fields entered 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 include my custom Census tags in many formal reports, I try to make a point of citing these sources at least once. 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.

BirthAssume MJH

I have made this custom tag the default for the TMG Hotkey (Ctrl-B) since 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. Causing this tag type to be assigned to the hotkey can only be done by renaming the standard tag assigned to this hotkey to this custom name, and then creating a custom tag with the standard name and sentences. In that way the default tag type can be this type, but I can change the tag type to the standard “Birth” name when I cite appropriate information. Depending upon what optional information is included, the sentences for this custom 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. Since it is in the Birth group I can change to a standard Birth tag type if birth data is confirmed. As of Version 8 I use a common color highlight for all *Assume and *-Can tag types.

BirthFind MJH

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.

BirthIlleg/Birth-Illegitimate MJH

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.

BirthMultiple, Twin

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:

Birth Group... || Role || = Equals || MULTIPLE

BirthNil MJH

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 any appropriate source pseudo person(s).

BirthOrder MJH

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.

BirthPar MJH

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

BirthRec MJH

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.

BirthStill/BirthStillborn MJH

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.

Reminders

BirthStill 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

Burial MJH , DeathAssumeBur MJH

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. 52 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) 53 to show their married names, e.g. “Mrs. Mary Jones”.

Burial Tag Type

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. 54 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. 55 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. 56 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.

DeathAssumeBur Tag Type

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. 57 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] 58 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. 59 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.

Burial/Cremation with Cemetery Witness

For all four tag types that refer to a Burial or a Cremation, I have added 60 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. 61 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. 62 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 ”). 63 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\; ”). 64 [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. Thus 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: 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 Entity Name for a carriage return: &#13; to break the lines. A maximum total of 60 characters can be used in this 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.

Reminders

Burial and DeathAssumeBurial Tag Types: cemetery and cemeteryMrs roles

If multi-line [WM5] pop-up text is desired, use the ISO carriage return: &#13; to break the lines.

BurialFind

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.

Cem-list-head MJH

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 should have Sort Dates to occur first), and the list of burials or cremations which occured at this site. No data is entered into this tag other than a Sort Date. The three Principal roles (Cemetery, Crematorium, and CemAndCrem) provide fixed sentences to produce a header above the tags sorted to follow in both TMG reports and the Second Site page for this 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 clear.

Census MJH

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.

ChildFind MJH

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.

Christning/Christening MJH

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.

Conflict, DataConflict, Caution, ResearchNote, WebNote, *Conflict

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.

Correspondence

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.

Created MJH

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. 65 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 are created as of the census date, Source people as of the publication date, etc. For some pseudo people a “creation” date is not needed or desired, so this tag is simply not used. In other cases a “bogus” date may be desired simply for sorting (e.g. the year “3000” for Interments). The narrative “Create” sentence may only need to indicate this “person” is being used to group (as a parent) other such people. In those cases I use the role Group so that the sentence will simply indicate that grouping with no date output, and enter the detailed portion of the Given name as an irregular Sort Date to keep multiple group “people” within their larger group in alphabetical order. The optional first split memo part <[M1]> in the sentence 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]> describes the common nature of those subordinate entities, often with the text “ in [L] ” when grouping by location. 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. 66 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 flag 67 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.

Reminders

Group role

If no memo text is desired, the memo 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.

Cremation MJH , DeathAssumeCrem MJH

I added the custom tag type Cremation to the Burial group. Like the DeathAssumeBur tag type described in more detail below, a DeathAssumeCrem was added 68 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.

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.

Cremation Tag Type

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

DeathAssumeCrem Tag Type

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] 71 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. 72 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.

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.

Cremation with Cemetery Witness

For all tag types that refer to a cremation, I have added 73 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.

Reminders

Cremation and DeathAssumeCrem Tag Types: cemetery and cemeteryMrs roles

If multi-line [WM5] pop-up text is desired, use the ISO carriage return: &#13; to break the lines.

Death MJH

The sentence in this standard tag type for the standard role Principal now includes the age variable [AE] 74 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. 75 [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.

DeathAssume MJH

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] 76 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. 77 [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.

DeathFind MJH

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.

DeathNil MJH

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.

Deeds

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

Descriptn/Description MJH

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

Dissolved MJH

This tag type 78 , 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. 79 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.

Divorce MJH 80

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.

Divorce Fl/Divorce Filing

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

DivorceAssume MJH

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.

DivorceFind MJH

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.

Duplicate MJH , DupNil MJH

I define a custom tag type that links two (and only two 81 ) 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.

Education MJH , Graduation

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.

EmigFind MJH

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.

Emigration MJH

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

Employment MJH

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.

Event-Misc MJH

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.

Guardian MJH , GuardianFind MJH

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.

Illness MJH

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.

ImmigFind MJH

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.

Immigratn/Immigration MJH

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

JournalIntro, JournalConclusion

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.

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

Land Transactions

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

A possible custom source template might be:

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

LocationLink

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.

Marr Assume MJH

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. 83 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 bann MJH , Marr Cont/Marriage contract, Marr Lic/Marriage license MJH

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

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 it. I seldom use a separate Marr Lic tag type, usually simply citing that source to the Marriage tag especially when both are on the same date. I decided not to show the parents in any of its sentences as they will usually show as part of the Marriage tag.

Marr Dummy MJH

This custom tag type was needed to allow my custom use of the NarrativeChildren tag type to output a list of non-Primary children in TMG Journal reports in some circumstances. As such it should only be selected for TMG Journal Reports. It has no effect on Second Site output and thus does not need to be selected as a tag type in that program but does no harm if it is. As the special custom use of the NarrativeChildren tag type describes, the Marr Dummy tag should only ever have one Principal. Further, its sentences are intentionally defined to produce no output. Even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems in either program since it produces no output, so I always enter it as a companion to any custom use of the NarrativeChildren tag. However, if there is another such Marriage Group tag, that other tag should be Primary. I enter nothing but a SortDate which is the same as the SortDate in the companion NarrativeChildren tag so they appear together in the non-Primary parent’s Details. To highlight that this tag type is only entered as a companion to the NarrativeChildren tag, I accent it with the same colors as the NarrativeChildren tag type.

Marr Find MJH

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.

Marr Nil MJH

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.

Marr Not MJH , Marr Coh, Marr Rel, Marr Never MJH

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

Marriage MJH , Src Link MJH

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

Milit-Beg/Military-Begin, Milit-End/Military-End, MilService MJH

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.

Misc MJH

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.

MiscFind MJH

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

MiscNil MJH

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.

MovedFrom MJH , MovedTo MJH

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.

MoveFind MJH

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.

NarrativeChildren MJH , FamilySectionNote

Description of these tag types

NarrativeChildren tags in TMG

NarrativeChildren and FamilySectionNote tags in Second Site

My Custom Usage of these tags

Listing Pseudo People’s “Children”
Listing Non-Primary Children
Listing Adopted Children
Listing Step Children
Listing other people

Family section TMG and SS custom output

Role reminders

The NarrativeChildren tag type is a very special tag type for customizing individual automatically generated Family sections in a TMG Journal report (or optionally Second Site Family Sections). It was added to TMG to override/replace the automatic “Child/Children of” and “There were no children of” headings above the Family sections of a Journal report. While I mainly use this tag to produce special output in Second Site, I also define my custom roles and sentences to produce similar output in TMG Journal reports. TMG (and optionally Second Site) automatically controls where the text of this tag will output, whether it will output in these reports, and which Family section heading will be replaced. This tag type only gives the user control of what text will replace the automatic heading.

Where the custom text from this tag will output is to be part of or replace an automatic Family section heading which would output for a Journal report Subject. In TMG the existence of a NarrativeChildren tag does not cause a Family section to output if it would not automatically output. Thus without an appropriate matching Family section being automatically produced there is no place in the TMG narrative to output this text.

Whether the custom text of this tag will replace an automatic heading is governed by a number of factors. The tag type must be selected for inclusion in the Journal report (or in Second Site) for these tags to output, and the individual tag must be marked Primary for the Principal which is the Subject of the Journal narrative or it will be ignored for that person’s Journal output. I try not to select this tag type for inclusion in non-Journal reports as for most other reports it is meaningless. 89 I usually prefer the Num Child tag type if I simply want a sentence with a list of various children’s names within the narrative of other reports.

Whether this NarrativeChildren tag will output also depends on whether an automatically generated Family section would be output for the specific Principal(s) who are assigned to this tag. A Family section is only output automatically by either software if there are children linked to the Principal(s) of this tag as Primary parent(s), or there is a tag in the Marriage group with its Principal(s) exactly matching the Principal(s) of this tag.

Which Family section heading will be replaced in the TMG Journal report narrative of a Subject, or the Second Site Person Page of a Subject, depends on the Principal(s) assigned to the NarrativeChildren tag. There can be multiple Family sections for this Subject. Either the section will be a two-Principal section with one for each different companion Principal, or a one-Principal section one where the Subject is the only Principal. Children can link the Subject as their sole Primary parent or as one of two Primary parents with multiple people as the other Primary parent. This Subject could be the sole Principal in a tag in the Marriage group, or one of two Principals with multiple spouses as the other Principal. The one or two Principals to the NarrativeChildren tag identifies which specific one or two Principals Family section will have its section’s heading replaced.

For example, if there is only one Principal for the NarrativeChildren tag there must be a one-Principal Family section for this tag’s replacement heading to output. That means either some children must link this Principal as their only Primary parent, or there must be a tag in the Marriage group which has this Principal as its only Principal. If there are two Principals for the NarrativeChildren tag there must be a two-Principal Family section with the same “other” Principal for this tag’s replacement heading to output. That means either some children must link both of these Principals as their Primary parents, or there must be a tag in the Marriage group which has both these Principals as its Principals. If heading and/or text is still desired to be output by a NarrativeChildren tag in a Family section when TMG would not automatically output a section matching this tag’s one or two Principals (no Primary children and no Marriage group tag), a “dummy” Family section can be forced to exist. A tag in the Marriage group can be added (usually my custom Marr Dummy tag type) 90 with matching one or two Principal which would by default produce a “no children of” the Principal(s). Then the NarrativeChildren tag with matching Principal(s) can completely replace that section’s default heading with the desired custom output.

What is output can vary widely depending upon the needs of the user. One of these tags can define replacement text which provides an alternative heading, and/or some additional narrative text either following or instead of the heading. The replacement text can even be null to prevent any heading for that Family section. No heading or text may be preferred when a couple has a tag in the Marriage group which would produce a Family section with a default heading, but has no children linked as Primary, and thus could eliminate the output of this section altogether. If there are two Principals in the NarrativeChildren tag, each can be assigned different sentence templates (or roles). Then each Principal’s heading of this hijacked two-Principal Family section could output different text when that Principal was the Subject of the Journal narrative or the Second Site Person Page.

What to output to replace the heading could include any other text desired, such as a list of children who did not link the Subject of the Journal narrative as a Primary parent. When the parent/child relationship tag in a child’s Details has not set this Subject as a Primary parent, that child will not be included in any automatically produced Family section of that Subject. If one only links the two biological parents as Primary for all children (as is my preference), then a list of other children with non-Primary relationships such as adopted children or step-children could be part of the replacement text of the heading of some Family section which would automatically output for an adopting parent or step-parent. In this case of replacing an automatically output Family section heading, the replacement text would first output a heading and list of the non-Primary children, then output the normal heading for this “hijacked” Family section. And if an appropriate one or two Principals Family section does not exist for this Subject, a “dummy” Family section with appropriate Principal(s) can be forced to exist with a dummy Marriage group tag as described above. Then the NarrativeChildren tag with matching Principal(s) can completely replace that dummy section’s default heading with only the heading and list of non-Primary children.

As mentioned above, if there are two Principals each could be assigned different sentence templates (or roles) to output different text in each Principal’s heading of this hijacked two-Principal Family section. However, if one Principal is to have a list of non-Primary children and the other is not, I prefer to either hijack a one-Principal Family section, or create a dummy one-Principal Family section to be hijacked for the list. For more details about using this tag to include a list of children not linked as Primary see my custom usage of this tag type below.

This special tag intentionally will produce no Witness output in either program. However, identifying people other than the Principal(s) may be useful in the custom replacement text output by this tag. Linking such people as Witnesses allows using Witness sentence variables instead of simply entering text for these Witness names. If these variables are used, the output produced by this tag can provide their ID numbers in the Journal report and the Hyperlink to their pages in Second Site. If Witnesses are linked I recommend that all Witness sentences be defined as excluded as a reminder that there is no way to output such sentences from this special tag type in either TMG or Second Site.

If a person does not have one of these special tags linked to them as a Principal, their Family section headings in neither the TMG Journal narrative when they are the Subject nor the Second Site Family section headings on their Person Page will be affected. I do use the NarrativeChildren tag type for both TMG Journal reports and Second Site pages. I have defined several custom roles with sentences to “hijack” automatically produced Family sections and replace the heading for common situations. For more details see my custom usage of this tag type below. The [PO] is conditional in the standard Principal role templates and also in many of my custom roles so the sentences generally work for hijacking and replacing the headings of either one-Principal or two-Principal Family sections. To highlight that these tag types only affect narration, I accent them with the same colors as my Transcript tag type.

NarrativeChildren in TMG

When this tag type was introduced TMG also introduced two sentence variables for use with this tag type. If used, the variable [:NONE:] should be the sole contents in a NarrativeChildren sentence template. This code will eliminate both the hijacked Family section header and any (ignored) replacement text in this tag’s TMG sentence whether or not this hijacked Family section’s list of Primary children will automatically output. A template with (only) this variable is usually only desired when it is known there will be no such automatic list, to eliminate the output for this otherwise automatic Family section. The special variable [:NoBirthPlaces:] in this tag’s sentence will eliminate the automatic output of birth locations within this Family section’s list of Primary children. These two special sentence format codes are recognized only by TMG (not by Second Site) and only in the sentence templates of this tag type. (See the TMG Journal Report Options on the Miscellaneous tab which also controls other output of these lists.)

This tag’s sentence can be defined with carriage returns for TMG to output multiple lines. The first line will appear as the heading of this section in the Journal report for the Principal. Any subsequent, possibly multiple, lines after the first carriage return will output as a narrative note under that heading. The typical heading of a list of children in a TMG Journal report is generally indented one tab stop, so it is appropriate to construct the heading text in the first sentence of this tag’s template to begin with the [:TAB:] format code. The note text in the subsequent sentences can either begin with one tab code to match the indentation of the heading, or use bracketing [LIND:][:LIND] codes to “somewhat” line up with the automatically generated list of offspring linked as Primary to this Subject which will follow. LIND codes will handle the line wrap if a lengthy note is added. As shown in several of my custom roles with sentences I prefer to begin each line in a LIND list of non-Primary children with a dash or a bullet ‘•’ (Alt+0149) character followed by the [:TAB:] format code to even better align with the Primary children list, and to make the beginning of each child’s entry clearer if their entry is long enough to wrap.

NarrativeChildren and FamilySectionNote in Second Site

Second Site also recognizes a custom tag type named exactly FamilySectionNote which can be optionally set as an equivalent alternative to using the NarrativeChildren tag type by specifying it as the Note Event to be used in the Second Site Family Sections configuration. This alternative tag type is not standard in TMG, and must be created as a custom tag type (usually in the Other tag group). If selected as the alternative, where, whether, which, and what this tag will output works the same in Second Site as the NarrativeChildren tag does when selected as the Note Event in Second Site. Normally this alternative tag type should not be selected for output in any TMG reports as this tag type is only meaningful in Second Site and will not affect any Family section heading in TMG.

I commonly use the TMG standard NarrativeChildren tag type for customization of my primary output of Second Site pages, as it can optionally be recognized by both TMG and Second Site. But either of the two tag types recognized by Second Site as a Note Event operates somewhat differently in Second Site output than the standard NarrativeChildren tag type does in the TMG Journal report.

Whether a Note Event tag will output depends upon some Second Site option settings. First, you must enable the “Family Sections” in the Second Site configuration for Pages / Person Entry to generate the TMG-equivalent automatic one or two Principal Family sections based on Marriage group tags and/or Primary children. Next in the configuration of this Section you must specify one of the two event tag types to be used as the “Note Event” for Family Sections: either the standard and default NarrativeChildren tag type, or the alternate custom FamilySectionNote tag type.

Whether the tag will output is also different than TMG in another way. If the Second Site options have been set and the tag sentence will output some text, Second Site will create a Family section for this tag’s replacement heading for the tag’s one or two Principals if there is not a matching one or two Principal Family section whose heading can be hijacked. Thus if there are two Principals for the Note Event tag, a two-Principal Family section will be produced by this tag even when a two-Principal Family section would not exist for these Principals as they are not the two Primary parents of any children nor have a Marriage Group event together. Also a one-Principal Family section will be produced by this tag even when a one-Principal Family section would not exist for this Principal as this Principal is neither the sole Primary parent of any children nor has a Marriage Group event without a second Principal. (Thus the “trick” mentioned above of adding my custom Marr Dummy tag type 91 with appropriate Principal(s) for TMG to create an appropriate Family Section whose heading can be replaced is not needed with Second Site, but won’t do any harm if that Marriage Group tag will produce no output.)

Which Family section heading will be hijacked by the Note Event tag is the same as TMG: it depends upon the one or two Principals of the tag matching the one or two Principals of that Family Section. This is true for whether the FamilySectionNote or NarrativeChildren tag type is set as the Note Event.

What will output as a replacement header and/or a following note is delineated differently in the tag’s sentence template than for TMG. By default in Second Site the Note Event tag sentence text will not replace the hijacked Family section heading (which is exactly backwards from its action in the TMG Journal report). Instead the text produced by the sentence will output as a narrative note following the default heading for that hijacked Second Site Family Section in the Subject’s page. Instead of TMG’s carriage return after the first sentence in the template to separate header from note, Second Site uses a special indicator of two escaped vertical bars ( \|\| ). This separates the replacement header text in front of the indicator from narrative note text following the indicator. To replace the header of the hijacked Family Section the indicator must exist in the Note Event tag output. This indicator is recognized only by Second Site but now allows the header to be multiple lines with carriage returns. This indicator will automatically cause the narrative note text following the indicator to start on a new line, so a separating carriage return after the indicator is not required.

In addition to this special separation indicator there also are Second Site-only sentence variables which now may be used in this tag’s output, such as those to output a lifespan for either Principal in the header: [LSP] , [LSPO] , [LSP1] , and [LSP2] . Since these Second Site codes and the special header indicator for this tag type are only recognized by Second Site, TMG’s special sentence codes should be used to hide them from TMG but expose them to Second Site.

Second Site does not recognize TMG’s special sentence codes [:NONE:] and [:NoBirthPlaces:] created in TMG only for use with this tag. Those codes will output in Second Site as text whether in the header or note portion. Thus the special sentence codes to hide them from Second Site should be used, which themselves should be hidden from TMG output.

A somewhat equivalent effect of the unrecognized TMG [:NONE:] code can be accomplished in Second Site. If a Principal is linked but their sentence consists of only the special separation indicator ( \|\| ) and nothing else, neither a heading will output nor a note, just the appropriate list of Primary children for this hijacked Family Section if any. (Contrary to the [:NONE:] code, if you mistakenly add text before or after the indicator it will output.) And if there are no children to be listed automatically for this hijacked Family Section, with this indicator-only template structure that Second Site Family Section which normally would automatically output will not produce output. My custom NoSentence role for this tag type uses the following single template to eliminate the hijacked Family Section headings in both TMG and Second Site.

[HID:][SS-HID:][:HID][:NONE:][HID:][:SS-HID][SS:]\|\|[:SS][:HID]

I choose to use only the NarrativeChildren tag type and not the the FamilySectionNote tag type as the Second Site Note Event. The NarrativeChildren tag type is recognized for this special purpose in both programs. Since one can force TMG to act like Second Site and force a Family Section to exist which would not automatically exist by including a tag in the Marriage Group (e.g. using the Marr Dummy tag type), there seems no value in using separate tag types for the two programs. While it requires constructing a complex sentence template which can handle both types of output, I prefer using only the NarrativeChildren tag type and thus having only one tag for output from both programs. Therefore I do not use the FamilySectionNote tag type.

My Custom Usage

I have defined several custom roles with sentences to simply replace a hijacked Family section heading for common situations. Further I have defined additional roles and sentences to produce lists of non-Primary children and optionally their Primary parents within the replacement heading when such have been identified. I put all the desired formatting for each program in the templates, and enter any text to output in split memo parts. For many roles there is also appropriate fixed heading text in the template. I construct the sentence templates in two parts: one part with formatting and TMG sentence variables for TMG output which is hidden by codes from Second Site, and a second part formatted with appropriate HTML codes 92 and Second Site variables for Second Site output which is hidden by codes from TMG.

Which custom role to use for this tag is based on whether the desired replacement heading requires one or two Principals, whether there is a matching automatic one or two Principal Family section which can be hijacked, and whether that hijacked Family section will have a list of Primary children so the replacement heading must include an appropriate heading for them. If a matching Family section does not exist to be hijacked, then a dummy matching Principal(s) Family section should be forced to exist, at least for TMG.

Listing Pseudo People’s “Children”

One set of custom usage of this tag type is with my custom roles SubLinks or SubOneLinks and NoLinks intended to hijack an automatic one or two Principal Family Section for Pseudo people Principals which may include a list Primary pseudo children. If it is a two-Principals Family Section I will invariably have some tag with this Principal pair in the Marriage group, like a Src Link tag, whether or not they have pseudo children. If it is a one-Principal Family Section I make a point to have some tag in the Marriage group, often the Marr Dummy tag. The intent of the NarrativeChildren tag is to replace the inappropriate term “children” in the default headings with a phrase using “subordinate entity”.

Which of these three roles to use depends upon whether the hijacked Family section for the pseudo children has one Principal or two, and whether this automatic Family section will include a list of pseudo children. The SubOneLinks role should be used for hijacking a one-Principal Family section which has a list of its Primary one-parent pseudo children. The SubLinks role should be used for hijacking a two-Principal Family section which has a list of their two-parent Primary pseudo children. The NoLinks role should be used for hijacking either a one or two-Principal Family section where there is no list of Primary pseudo children.

If no list of children exists but either SubLinks or SubOneLinks is used to hijack a Family section, the replacement heading would still (sort of) work above the non-existent list but I try to use the custom role NoLinks instead so the family entry does not look like a mistake. However, if later I add a child which would list in a Family section which previously had no list, and the NarrativeChildren tag hijacking that Family section is using the NoLinks role, I will need to remember to change the role on that tag.

I use a Date in the NarrativeChildren tag the same as the Date in the tag in the Marriage group, and a SortDate the same as the SortDate in that tag in the Marriage group with a trailing ‘?’ to make it sort after the Marriage group tag. I have found no value to including a Location as part of this tag as I don’t output that information in this tag’s sentences, even though the tag in the Marriage group may have a Location. While one could (and does) try to be consistent to have the Male Principal of a couple always P1 , with this tag’s custom sentences there is no special requirement for this.

Three additional custom Principal roles are designed specifically for Pseudo Repository people: ReposParent, ReposSrc, and ReposParent+Src. Repository people will either be non-Primary parents of Pseudo Source sons for sources stored in that repository, or Primary parents of subordinate Repository daughters. Usually Repository people are not linked as a spouse to any other entity (e.g. with a Src Link tag), so any Family section would be for only one-Principal. The intent of these roles is first to hijack an automatic Family section with a list of Primary pseudo daughters to change the text to reflect the pseudo nature of these children. Second the intent is to include a list of any non-Primary children, usually Source sons, within the replacement header of the automatic Family section, or within a replaced dummy Family section heading if there is not an automatic section. (See below for more details about non-Primary children lists.)

The ReposParent role should be used for hijacking a one-Principal Family section which only has a list of Primary Repository daughters, thus Marr-Dummy is not needed. The ReposSrc role should be used for hijacking a one-Principal Family section which has no Primary children list, but the replacement heading is to list non-Primary Source sons. Thus a Marr-Dummy tag is needed to force this section and these non-Primary children are linked and listed in the split Memo parts as described below for any non-Primary children list. The ReposParent+Src role should be used for hijacking a one-Principal Family section which has Primary Repository daughters and the replacement heading is to list non-Primary Source sons. A Marr-Dummy tag is not needed but these non-Primary children are linked and listed in the split Memo parts as described below. If more than nine non-Primary Source sons exist, link all Source children as child1 and use [M1] to output all the Source children as a single comma-separated list as described below.

Listing Non-Primary Children

Using this tag type can provide symmetry to the Second Site option to list non-Primary parents on a child’s page as a result of any non-Primary (usually non-Biological) relationship tags. NarrativeChildren tags can hijack an automatic Family section to (also) list any non-Primary children in that replacement heading on a parent’s page even if the symmetric equivalent non-Primary relationship tags are not used. Five custom Principal roles are defined for adding lists of non-Primary children to replacement headings of hijacked Family sections: OthParent for a list with generic or multiple relationships, Adoptor(s) and AdoptorAlone for a list of just adopted children, plus StepParent and StepParentAlone for a list of just step children. Which of these roles to use to add a particular list of non-Primary children is described more fully below and depends upon whether the list of non-Primary children is for one or two Principals, whether there is a matching automatic one or two Principal Family section which can be hijacked, and whether that hijacked Family section will have a list of Primary children so the replacement heading with the non-Primary children list must include an appropriate heading for them. If a matching Family section does not exist to be hijacked, then a dummy matching Principal(s) Family section needs to be forced to exist, at least for TMG.

A list of non-Primary children could be caused to output even if symmetric equivalent non-Primary relationship tags are not entered for this parent/child, although I try to maintain that symmetry. I suggest (and try to ensure) that if any parent/child relationship tags are set non-Primary for the child and these parents are listed in the child’s narrative, then companion NarrativeChildren tags also are created to produce lists of these non-Primary children in hijacked Family section headings in the parent’s narrative, and vice versa.

I choose to only link who I believe are the two biological parents of children as their Primary parents. Adopted and step parent/child relationships are two common types of non-Primary relationships, and I have defined custom roles specifically for these standard relationships. I only use a SortDate with an empty Date and set it the same as the SortDate in the tag in the Adopting tag, or in the tag in the Marriage group for the step parent with the birth parent, but with a trailing ‘?’ to make it sort after those tags.

Although this tag will not output Witness sentences, I defined general Witness roles child1, child2, child3, etc. to link the non-Primary children and separately identify each in their separate split Memo part. At least one child, usually using the child1 role, must be identified in the first split memo part for children for the sentence templates to work properly. Subsequent childN roles in their split memo parts are optional. These childN Witness roles can be used in each child’s split memo part to output their name and also to produce IDs or hyperlinks. Do not include carriage returns beginning or ending each split memo part as the list will then be double spaced.

If I do not wish to add separate information for each child (or the number of children is larger than nine), all adopted children can be entered with the Witness role child1. Both programs will then list all people assigned this common role in a single comma-separated list, and the memo would simply be:

[R:child1]

Commonly all the non-Primary children linked to a parent have the same Primary parents, so the sentence templates of many of my custom Principal roles for listing non-Primary (and non-Pseudo) children use one or more of three special heading Witness roles in their replacement heading text to identify these Primary (usually biological) parents: bioParent, bioMrs, and bioMr. If any of these three special parental Witness roles defined for the replacement heading are used, the heading in the template uses text which includes something like “who are children of” to identify the Witness person(s) as Primary parent(s) of these children. If there is only one known Primary parent that Witness should be linked with the heading role bioParent. If both are known but not married, they both should be linked as Witnesses with the role bioParent using whatever Name tag is appropriate at the time of birth. But if the common Primary mother linked is a woman who has a custom Name-Marr-Title tag which includes the surname of her husband (at the time of the birth of the child), she should be linked as a Witness with this name variation and the role bioMrs. If the husband is known, is the husband of bioMrs, and is also a common Primary parent for these children, he can optionally also be listed in the heading by being linked as a Witness with the role of bioMr, but only if the role bioMrs is also used for the birth mother. If the common birth father is not the husband of the married mother at the time, she still can be linked with the bioMrs role, but he can be linked with the bioParent role. If bioMrs role is used, the adoptor sentence templates will output the mother Witness in the heading using her husband’s married surname plus her maiden surname. When any of these three heading parental roles are used, each split Memo part would only include the information about that non-Primary child. For example:

[R:child1] b. c 1951, d. 1963||[R:child2] b. c 1957

If the Primary (usually biological) parents of the non-Primary children are not common to the entire added list then none of these three special heading Witness roles should be used with any of the custom Principal roles. For this case the generic Witness roles of parents1, parents2, parents3, etc. were defined and can be used for one or both biological parents to output within that childN matching split memo text rather than in the heading. If two parents are assigned the same role, that role’s variable will output both names. The Primary parents variable can be used separately in the specific split Memo part for their child. For example:

[R:child1], son of [R:parents1], b. c 1951, d. 1963||[R:child2], daughter of [R:parents2], b. c 1957||[R:child3] b. 12 Sep 1959

Listing Adopted Children

I first customized this tag type with specific roles to list adopted children, as I have several such relationships in my projects. Described above as one of the tags associated with Adoption, I describe a custom use of the NarrativeChildren tag type for Adoption to insert a list of non-Primary adopted children in the replacement heading of a hijacked automatic Family section of that adopting parent. For that purpose I defined two custom roles for the NarrativeChildren tag for hijacked Family sections: Adoptor(s) and Adoptor(s)Alone. The Principals of this NarrativeChildren tag will be either the one parent who adopts, or the couple who adopts together. If only one person adopts all these children then they are the sole Principal on this tag, if both adopt this list of non-Primary children then they are both linked as Principals. Which role to use depends on whether the Principal(s) who adopt have Primary children. If the sole Principal has one-Parent Primary children, or the two Principals have shared two-parent Primary children, use the role Adoptor(s) for the one or for both. Otherwise use the role Adoptor(s)Alone for the sole Principal or both Principals. If a Family section with matching Principal(s) to this tag’s Principal(s) does not exist to be hijacked (because there are neither Primary children nor a tag in the Marriage group for this tag’s Principal(s)), then a dummy matching Principal(s) Family section needs to be forced to exist, at least for TMG. This can be done by using the Marr Dummy tag type 93 with Principal(s) exactly matching the Principal(s) of this NarrativeChildren tag.

Although this tag will not output Witness sentences, these roles also use the defined the general Witness roles child1, child2, child3, etc. as described above. At least one non-Primary adopted child must be identified, usually using the child1 role, must be identified in split memo part [M1] for the sentence templates to work properly. Subsequent childN roles and split memo parts are optional. They can be linked using whatever name variation is appropriate to the sensitivity of the situation. The details of each child is entered in separate split Memo parts. Do not include carriage returns beginning or ending each split memo part as the list will then be double spaced.

Commonly all the adopted children have the same Primary biological parents, so the three special heading Witness roles bioParent, bioMrs, and bioMr can be used as described for listing non-Primary children if this is not sensitive. The sentence template of these Adoption Principal roles will output common parents in the heading to identify them. Otherwise if desired one of the generic Witness roles of parents1, parents2, parents3, etc. can be used within that childN matching split memo text as mentioned above. For more details of the usage for these relationships with these Principal roles in the NarrativeChildren tag see the examples for Adoption using this tag type as part of documenting that event in that section.

Listing Step Children

Like adopted children, a NarrativeChildren tag can be used to insert a list of non-Primary step children in a hijacked automatic Family section on a parent’s page. This list could be caused to output even if symmetric equivalent non-Primary *-Step relationship tags are not entered for this parent/child, although I try to maintain that symmetry. Step children generally exist where they are biological (and thus Primary) to a parent who subsequently marries another spouse. Therefore typically the children have a *-Step relationship with only one person, the new spouse. However if the birth parent marries again the children could have a *-Step relationship with multiple people, but each set of relationships still would be single-parent non-Primary relationships. Likewise a step-parent could marry again and have multiple sets of step children from each spouse, but each set still would be single-parent non-Primary relationships. Thus in all cases the NarrativeChildren tag inserting a list of step children into a hijacked Family section heading will have only one Principal, the one step parent of these children.

Similar to Adoption, I defined two custom Principal roles with special codes in their sentence templates for the NarrativeChildren tag for listing step-children in hijacked Family sections. The one step parent can be linked as the sole Principal to this tag type as either StepParent or StepParentAlone. Which role to use depends on whether this sole step parent Principal has single-parent Primary children. If this Principal does have such children use the role StepParent for the Principal to also produce the “Children of” heading for those children. Otherwise use the role StepParentAlone for the sole Principal which will not include that heading. The role StepParent can be used when there are no Primary children if the heading for an empty list of single-parent Primary children is desired, but that is unlikely to be desired. If a single-parent Family section for this sole Principal does not exist to be hijacked (because there are neither Primary children nor a tag in the Marriage group with this Principal the sole Principal), then a dummy matching one Principal Family section needs to be forced to exist, at least for TMG. The most common case is where there are no children for which this Principal is the only Primary parent, so a single-parent Family Section would not exist. This can be created by using the Marr Dummy tag type 94 with this Principal as its sole Principal. Even if this Marr Dummy tag is not needed, it will cause no problems in either program since it produces no output. Therefore I always add it as a companion to a single-Principal NarrativeChildren tag to output step children.

Similar to the description for adopted children above, I also use the custom Witness roles child1, child2, child3, etc. to link the step children and separately identify each in their separate split Memo part. At least one step-child, usually using the child1 role, must be identified in split memo part [M1] for the sentence templates to work properly. Subsequent childN roles in their split memo parts are optional. Do not include carriage returns beginning or ending each split Memo part as the list will then be double spaced. For example:

[R:child1] b. c 1951, d. 12 Oct 1983||[R:child2] b. c 1957, d. 24 Mar 1992

If you do not wish to add separate information for each child (or the number of children is greater than nine), all step children can be entered with one child Witness role, e.g. child1. Both programs will then list these Witnesses as a single comma-separated list, and the memo would simply be:

[R:child1]

Similar to Adoption, the special Witness heading roles of bioParent, bioMrs and bioMr can also be used to link the Primary (biological) parent(s) of these step children and name them in the heading. This is usually desired as the identification is likely known and not sensitive. If all birth parents for a list are the same, these roles can be used as described above for listing non-Primary children. Usually they do have common parents, one of which is now the spouse of the step parent. If all Primary parents are not the same, for example the step-parent marries again to a spouse with children, the different Primary parents can be linked instead with the parentsN Witness roles described above and identified in each child’s memo rather than in the heading.

[R:child1], son of [R:parents1], b. c 1951, d. 1963||[R:child2], daughter of [R:parents2], b. c 1957

Lists of both Adopted children and Step Children, and/or non-Primary children with other relationships

There can be cases where non-Primary children in a list have a relationship which is neither step nor adopted, or have multiple different relationships. For such circumstances I also defined the generic custom Principal role OthParent which can be used to replace a default heading of a hijacked Family section with up to three types of text. The three types of text entered in the split Memo are: an optional leading replacement heading describing the non-Primary list, a narrative note listing at least one child of a list of non-Primary children, and an optional trailing Primary children heading for after the narrative note and before the list of Primary children which may be automatically generated for this hijacked Family section. Since all text, both headers and list, are entered in the memo, this tag type could be used for listing a set of people of any kind(s) of non-Primary relationship(s) in a person’s hijacked Family section heading. If a Family section with matching Principal(s) does not exist to be hijacked, then a dummy matching Principal(s) Family section needs to be forced to exist, at least for TMG.

The template defines [M1] to contain the leading optional heading above the following narrative note containing a list of people. [M2] is defined to contain a trailing optional heading for after the narrative note with list and before a possible following list of Primary children to be automatically generated for this hijacked Family section. If there are no Primary children for the Principal(s) of this tag, this split memo part can be marked as empty (i.e. contain a single space character). [M3] is required to contain text to identify (at least) one non-Primary child in the list, usually using the child1 role. [M4]...[M9] contain optional list entries for additional people up to a total of seven entries. Any of the predefined custom Witness roles of child1, child2, etc. parents1, parents2, etc. and bioParent, bioMrs, and bioMr may be used in the split memo parts for the headings and/or non-Primary children entries if useful and such Witnesses are linked to the tag. Note that the bioParent, bioMrs, and bioMr roles are not automatically in headings like they are in other roles, but can be part of the split memo parts for headings if desired. For examples of the use of these Witness variables in other roles see the Adopted children and Step children lists above.

A full and complex example is when a person is the sole parent of some Primary children, is also the sole parent to adopt non-Primary children, and also gains non-Primary step children on a subsequent marriage. Only one NarrativeChildren with a single Principal can be Primary to hijack the one automatic single-parent Family section and output the desired replacement headings with lists of this set of multiple non-Primary children relationships and automatically following Primary children. For example:

Other children with [P]||Children of [P]||[R:child1] b. c Sep 1860, d. c 1910; step daughter, child of [R:bioMrs] (née [RL:bioMrs]) and [R:bioMr]||[R:child2] adopted c 1891, b. c May 1889, child of [R:bioParent] and an unknown father||[R:child 3] b. c 1879, presumably son of [parents3], in the family as of 1985 and is possibly just a ward

Output of custom family sections in both TMG and Second Site

If customization is desired of family sections for selected parents in both TMG Journal reports and Second Site, one first must recognize that Second Site will permit only one or the other of NarrativeChildren or FamilySectionNote tag types to be used as the potential Note Event in the Family Sections for the entire site. Further, as noted above there are sentence variables and indicators which TMG recognizes that Second Site does not, and vice versa. Finally only in Second Site can this tag force a Family Section list heading when there are neither Primary children nor a matching Principal(s) tag in the Marriage group. For this reason one of two approaches should be chosen. One approach is to always enter both tag types for these parents, and duplicate the information but use the appropriate different codes and formatting in each tag type, using NarrativeChildren strictly for TMG and FamilySectionNote strictly for Second Site output. With this approach the NarrativeChildren tag type should be selected for output in TMG (Journal) reports only, and its sentence would be constructed for that output only. The alternative FamilySectionNote then would be set as the Second Site Note Event, selected for inclusion in Second Site and not in TMG, and its sentence would be configured for that output only. Alternatively one could use only the NarrativeChildren tag type and customize the sentence template to produce appropriate output for these parents in both TMG and Second Site. This will require using appropriate embedded format codes to both “hide” the properly formated TMG sentence template and TMG codes from Second Site, and vice versa. As stated above, I prefer using only the one NarrativeChildren tag type and thus having only one tag to enter, with an appropriate two part template which works for both software programs.

Reminders

NarrativeChildren role: OthParent

General purpose role for a Principal with at least one non-Primary (other) child where all text is entered in split memo parts

M1 - leading optional heading above list of non-Primary children entered in memo

M2 - trailing optional heading above list for any Primary children which may automatically follow

M3 - required entry for one non-Primary child

M4...M9 - optional entries for additional non-Primary children

NarrativeChildren role: Adoptor(s)

Use with an optional [PO]. Any Principal with this role adopted all of this list of children, and has Primary children which will follow. Thus Marr-Dummy is not needed. If no PO is linked, this Principal is the only parent to adopt the children and has single-parent Primary children. If a PO is linked, both Principals adopted the children and share the two-parent Primary children to follow.

Optionally link Witnesses bioParent, or bioMrs and bioMr, if all adopted children are from the same parent(s), else link matching parentsN Witnesses and mention in memo part.

Split memo parts must include text in [M1] for at least one adopted child, e.g.

[R:child1] b. date, d. date||[R:child2] b. date

NarrativeChildren roles: Adopter(s)Alone

Use with an optional [PO]. Any Principal with this role adopted all of this list of children, but has no Primary children which will follow. Thus Marr-Dummy may be needed. If no PO is linked, this Principal is the only parent to adopt the children and has no single-parent Primary children. If a PO is linked, both Principals adopted the children and have no shared two-parent Primary children.

Optionally link Witnesses bioParent, or bioMrs and bioMr, if all adopted children are from the same parent(s), else link matching parentsN Witnesses and mention in memo part.

Split memo parts must include text in [M1] for at least one non-Primary child, e.g.

[R:child1] b. date, d. date||[R:child2] b. date

NarrativeChildren role: StepParent

Use with only one Principal. Principal with this role has step children and has single-parent Primary children. Marr-Dummy tag not needed.

Optionally link Witnesses bioParent, or bioMrs and bioMr, if all step children are from the same parent(s).

Split memo parts must include text in [M1] for at least one step child, e.g.

[R:child1] b. date, d. date||[R:child2] b. date

NarrativeChildren role: StepParentAlone

Use with only one Principal. Principal with this role has step children but has no single-parent Primary children. Marr-Dummy tag may be needed.

Optionally link Witnesses bioParent, or bioMrs and bioMr, if all step children are from the same parent(s).

Split memo parts must include text in [M1] for at least one step child, e.g.

[R:child1] b. date, d. date||[R:child2] b. date

NarrativeChildren role: ReposParent

Use with only one Principal. Principal with this role only has Repository daughters where only this Principal is linked as the Primary parent. Principal has no non-Primary children.

Marr-Dummy not needed. No memo is output

NarrativeChildren role: ReposParent+Src

Use with only one Principal. Principal with this role has both Repository daughters where only this Principal is linked as the Primary parent, and non-Primary Source sons. Marr-Dummy not needed.

Split memo parts must include text in [M1] for at least one Source child, e.g.

[R:child1]||[R:child2]

If more than nine Source children exist, link them all as child1 and only use [M1] for the comma-separated list.

NarrativeChildren role: ReposSrc

Use with only one Principal. Principal with this role has only non-Primary Source sons.

Marr-Dummy needed. Split memo parts must include text in [M1] for at least one Source child, e.g.

[R:child1]||[R:child2]

If more than nine Source children exist, link them all as child1 and only use [M1] for the comma-separated list.

Natlzation/Naturalization MJH

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.

Note MJH , NoteSensitive

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:] ”. 95 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 explicitly exclude it from output. 96 For such sensitive data I use my custom AnecdoteSens tag type instead.

Num Child/Number of children MJH

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.

Num Marr/Number of marriages MJH

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.

Obituary

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.

Occupation MJH

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.

Ordination , Ordained MJH

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.

PsgrList/Passenger List MJH

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.

Related MJH , Generation

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] = “were godparents of” and [WM1] = “was a godchild of” . 97 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.

RelateFind MJH

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.

Research

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

ResDone (or ResLog ) - to document completed research, possibly negative

ResSurn - to link to pseudo surname person

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.

ResLead - leads that are intended to be followed

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, …”

ResRept - note about research that is intended to print on reports

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.

Residence/ResideOrig , ResidedAddress MJH

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.

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

ResideFind MJH

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.

Sex Change

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.

TestTag MJH

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.

Transcript MJH

This custom tag type is 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. This tag type with its custom sentences is designed to use one each or just one of two Principal roles: Subject and Extract . As of Version 8 I color highlight this tag type. 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 the 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 pseuod 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. I usually avoid selecting Transcript tags from printing for most reports and use them just to record the raw information, but use the appropriate “normal” tags to record the information for narrative sentences. Since these tags are seldom selected to print, I tend to use a special Version 8 tag type color highlight for such tag types. I find it simpler to have a separate custom Individual Narrative report for printing Transcript tags that selects all real people that are Principals and all pseudo people that are Principals or Witnesses to a Transcript tag.

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 below) 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)

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

If you want the tags sorted in the order their extracts appear in the source, you might use appropriate variations for the sort date (see entering dates). However since the tag date refers 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 would 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 Source Person.

Widow(er)

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.

Will, Codicil, Probate

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 the standard tag types Will and Codicil in the Other group and Probate in (for probably some legacy reason that I do not understand, possibly to sort after Death) 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 types 98 have been proposed to deal with these different events. 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.)

WillNunc - When a nuncupative will is given verbally.

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

WillProve - When the court approves (proves) the 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.

WillHeirs - A legal proving of the heirs of an individual.

WillDowerPet - Petition of Dower

WillDowerRel - Release of Dower

EstateInvt - When an inventory is taken of an estate.

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.


1. This list only 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. 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.

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

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

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

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

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

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

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

16. The National Genealogical Society re-published some papers on how non-biological relationships should be treated in their Special Publication No. 64, Joan Ferris Curran, Madilyn Coen Crane, and John H. Wray, "Numbering Your Genealogy; Basic Systems, Complex Families, and International Kin" (Arlingtin, VA: NGS, 1999). The article on adoption contained in this special publication was originally published in their Quarterly, June 1995 (Vol. 83, No. 2) pages 85-95.

17. Preference set under “File >> Preferences >> Program Options >> Tag Box - Show witnessed events”

18. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “ -<[M0]>[:NP:] ”) its presence is enough to generate an automatic list in TMG. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other tag should be Primary.

19. The HTML codes needed in the sentence templates of these roles are likely dependent upon the Second Site Theme chosen. The codes in the sentence templates of these roles work for my use of the “nonzero-brown” Theme using the Person Entry “Narrative” format. I have not tested it with any other Second Site configurations.

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

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

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

23. 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]”).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38. Note the remaining bug where sensitive data in a Name is always included in an Individual Narrative Index.

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

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

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

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

43. If the husband’s married surname includes a non-empty PreSurname field, for the spouse I 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)”

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

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

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

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

48. from Carol Simpson on the TMG ListServ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63. While a TMG report will put a space between the name and this [WM1] leading punctuation, 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.

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

65. 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, but need to review other roles and how the Place should be output.

66. 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. The NoSentence role has also not been added to other projects as they do not (yet) have Interments people. Need to test these uses in my other projects.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

83. 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:
 ( 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).
 ( 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:

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

then change the last two conditions 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.

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

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

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

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

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

89. The NarrativeChildren tag type is designed for output only in the Journal report as part of its automatic offspring section. However I need to test (further) which other report types will output this tag if it is (mistakenly) selected for output. So far tests show it will output in: Individual Detail.

90. Even though the sentence template for such a dummy tag in the Marriage group can be excluded from output (e.g. “ -<[M0]>[:NP:] ”) its presence is enough to generate a TMG Family section for the Principal(s). This tag is only required for TMG output, but does no harm for Second Site if the output is excluded.

91. Even though the sentence template for such a dummy tag in the Marriage group can be excluded from output (e.g. “ -<[M0]>[:NP:] ”) its presence is enough to generate a TMG Family section for the Principal(s). This tag is only required for TMG output, but does no harm for Second Site if the output is excluded.

92. The HTML codes needed are likely dependent upon the Second Site Theme chosen. The codes in my sentence templates for these custom roles work for my use of the “nonzero-brown” Theme using the Person Entry “Narrative” format. I have not tested the output with any other Second Site configurations.

93. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “ -<[M0]>[:NP:] ”) its presence is enough to generate an automatic list in TMG. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other tag should be Primary.

94. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “ -<[M0]>[:NP:] ”) its presence is enough to generate an automatic list in TMG. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other tag should be Primary.

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

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

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

98. Many were proposed by Teresa Ghee Elliott on the TMG-L ListServ.


Disclaimer

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke. I am simply a satisfied user of this software package and have constructed these documents to aid me in its 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® using its hyperlink and HTML conversion features.

©MJH Consulting, 1995-2018. All rights reserved.