My Way ©MJH 1996-2017; Index

Modified January 31, 2017 5:47 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, *-Oth
Custom: *-Bio2, *-Can, *-Nil

Name Tag Types

Name Tag Styles: AllFields name style
Name Tag marked Primary, Inferred Name Parts
Name-Adopted, Name-Assume, Name-Baptism, Name-Birth, Name-Chg, Name-Comm, Name-Index, Name-Loc-Var, Name-Marr (Name-Marr, Name-Married, Name-Marr-Title, Name-Maiden), Name-Nick, 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, 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 Find, 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. 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.

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 People. Those colors are: font = Light Yellow (one right from top left), background = Green (third from left, four down)

Transcript tag type plus the NarrativeChildren and Journal* tag types

I generally use both Transcript and NarrativeChildren tags with Pseudo People and they primarily affect narration. I set this color similar to the color scheme I use to accent the Pseudo People, but slightly more grey. I also use this color for the Journal* tag types. I use: font = Purple (diagonally up one from bottom right), background = Grey (next 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 data which it is not really 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/child relationships, the adoptive parents can be more easily identified in that output. Further, customizing information in the Family Sections can produce links in the parent’s narrative to adopted children which have a output non-Primary parent/child relationship with this parent.

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. The extreme example of the two person approach involves two separate datasets, one for each “person” and lineage, where each dataset really contains a one person approach. Second Site’s options to output output non-Primary parent/child relationships as well as customizing the list of 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.

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. And they 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. 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. However, the list of non-Primary children can be added to the automatically listed Primary children in either in the parent’s Journal report in TMG or in the parent’s Family Section in Second Site. A NarrativeChildren or equivalent tag with the non-Primary parents as Principals is designed to add information to these children lists. The sentence output of the tag simply needs to include the list of non-Primary children as part of the information this tag will add at the beginning of the automatic list of Primary children. 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. Switching the offspring from one parent “person” to the other is very difficult, especially as each person does not have 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 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

In addition to using the standard *-Adopted(*-Ado) relationship tag type, and not using 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.

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

 

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

 

NarrativeChildren can be used to include a list of any non-Primary children as a note at the beginning of the TMG Journal report parent’s list of children, and at the beginning of the Second Site Family Section parent’s list of children. The sentence of this tag must be structured to output all the information about these non-Primary children as part of the note text it produces since they will not be automatically output in the lists produced by these sections by either software. The text (which includes the list of non-Primary children) will output from this tag ahead of the automatically generated list of those children linked as Primary to this parent.

I defined the custom role Adoptor for this tag to link the parents as Principals which produces the standard header, and expects the list of non-Primary children to be entered in the memo. I defined several adopted* roles to link those adopted children as Witnesses who do not have their standard *-Adopted(*-Ado) relationship tag type linked to the adopting parent as Primary. While this tag will produce no output in these children’s narratives, linking them as Witnesses allows using a Witness sentence variable for their name in the list in the memo. By using Witness variables instead of text for the non-Primary children’s names in the memo list, the Note produced by this tag will not only list the children but also provide the ID numbers in the Journal report list and the Hyperlink to the child in the Second Site Family Section list. For Second Site this makes a good parallel in a parent’s page with also using the Second Site option for the Parent Section in the child’s page which can list the non-Primary parents. The witness sentences (e.g. adopted* ) are double excluded as I know of no way to output that sentence in either TMG or Second Site. The sentence template for the parent’s Adoptor role is complex and in two parts since it is designed to work for both TMG Journal reports and Second Site. It is designed so that the memo only contains the list of adopted children and any data which is also desired for output for each of them. If different heading text is desired than the text in this tag type’s global definition, this can be accomplished by changing the default global sentence to become a local sentence and altering the default heading text in that sentence. Be careful to change the text in both parts of the sentence: the part for TMG output and the part for Second Site. I have left my default heading very generic since it normally serves as the heading for both the list of non-Primary children in the memo and the automatically produced list of Primary children which will follow. With this generic sentence template, the text in the main tag memo can be adapted to a variety of situations as shown below.

As examples of tag memo text for use with these custom roles, if there is only one non-Primary child, one could simply link it using the role Witness, and enter a simple main tag memo like:

[WO] was adopted, b. c 1951

If there is more than one non-Primary child, one should link each with a separate role of adopted1, adopted2, adopted3… Then the memo can reference each child separately, and there would be a carriage return entered between each line for each adopted child like:

[R:adopted1] was adopted, b. c 1951, d. 1963

[R:adopted2] was adopted, b. c 1957

Finally, if one wanted to produce a separate heading for the list of Primary children which will automatically follow, this also could be done with appropriate text in the memo:

One adopted child [WO] b. c 1951

 

And the following biological children:

Note that a NarrativeChildren tag will only change the heading and/or add a note to the beginning of the list of children for those parents linked as Principals to such a tag. Thus the children’s list for all parents without such a tag will use the default heading and not contain any note. So only parents who have non-Primary children would benefit by this tag added to provide the list of such children.

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

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 19 for “candidate” or potential parent/child relationships. This is when I think a pair of people might be parent/child, but am very uncertain. 20 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 . For names where I 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 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 to provide dual sorting and index entries of her married name. If her Maiden name has a non-empty PreSurname field, I simply include it in the “Maiden” field with the surname. See the “Married” name style described below in that tag type.

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

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 Given in the name tag if there is intended to be a blank Given name to avoid the missing name text, e.g. “(?)”. A blank given name with an alternate surname will automatically take on the Primary given name. For more details concerning blank name parts, see also the Blank Name Parts topic in the Data Entry Chapter. Note that the variable [N] used in sentences 21 for Name-Var tags does not infer empty values from the Primary name in narrative report output but will only output the data entered in that tag. However, when a specific Name variation is selected as the name associated with a tag, sentence name variables for name parts that are blank (e.g. [PF] ) will infer their empty values from the Primary name. 22 A Name-Var could also be used (such as the custom Name tag Name-Index ) to record other (standardized?) spellings of this family name, even if never used by this person, to show linkage and produce an entry in indexes. See my data entry notes for names for additional examples and entry standards for cultures with different name structures and conventions, e.g. 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-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. 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). 23 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 sentence to double exclusion marks “--” 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. Since its sentence is double exclusion markers (with <[M0]> which is not required but included to make it clear the memo will not output) the memo can be used to document why I am including this tag as it will show in the Details section but will not output in reports. (See also my similar custom Name-Surname-Sort tag type for its obvious but different and more focused purpose, 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. 24 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 25 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. 26

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

There are multiple suggestions to enter a maiden surname in the suffix field of a Name-Married tag, either with the exclusion character 28 -(née Maiden-surname) ”, or using sensitivity braces, 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 29 (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 and use the OtherName field for their married surname. 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 double exclusion tag sentence text ‘--’ can be used to exclude it 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. Thus I generally select my custom Name-Marr-Title tag type to be included in reports and indexes, but do not select the standard Name-Married tag type to be included.

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. I created the Name-Marr-Title tag type with a double-excluded sentence 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. 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]> ”. For example if the tag has two Principals entered P1:male and P2:female, and you desire the woman’s title to output but the Subject listed first, these sentence variables output the subject’s name first as respectively: “Jacob and Mrs. Elizabeth Sark” and “Elizabeth 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 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 and add these back in to the templates, but currently choose to label them “Blank” and not include them in the married name

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.

If maiden name has a PreSurname, must enter it and the Surname.

OtherName [Married]

Only the surname 30 of this spouse

Output

[Mrs.] [GivenName] [Married]

Surname sort

[Married], [SortGiven] [Maiden]

Surname display

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

Given sort

[SortGiven]    31 [Married] [Maiden]

Given display

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

Children/Siblings

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

I usually exclude Name-Married tags from printing, or one could define its sentence as “ --<[M0]> ” (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, so 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.

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-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 were non-empty, 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, 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 usually 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. Since its sentence is double exclusion markers (with <[M0]> which is not required but included to make it clear the memo will not output) the memo can be used to document why I am including this tag as it will show in the Details section but will not output in reports. 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, 32 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 33 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. 34 (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 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. 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. 35

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 thus default. I use the 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 text about the birth appears in the parents’s narratives. (See also the BirthPar tag type.) I added [PAR] to the standard Principal sentence, deleted the role Child , and added the Principal role ChildOnly for 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 you have no printable fields in a Birth tag, that tag will not appear in narratives, even though the sentence would make you think it should. This allows the creation of Birth tags with sort dates only, in order to sort the children of a couple correctly when no dates are known and you don't wish to estimate one. The BIRTH ORDER flag came before the Sort Date in the development of TMG and could be used for this 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 most 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 the source usually includes the person’s age as 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 Principal sentence, 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 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. 36 [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 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. 37 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 internments at a specific site as these women are invariably recorded using their married names. 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) 38 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. 39 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. 40 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”).

[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 usually qualifies the following burial location. Typically I enter the cemetery name in [M4] instead of including it as part of the MPL location record (e.g. “in lot K-4 in the Alberson Cemetery”). 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 [M4] also can provide an appropriate preposition when used with an ‘*L’ role.

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

Although the sentence of this custom tag for the standard role Principal includes the age variable [AE] 42 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.

[M4] is semi-optional text which is only used to qualify the following burial location. Typically I enter the cemetery name in [M4] instead of including it as part of the MPL location record (e.g. “in lot K-4 in the Alberson Cemetery”). 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 [M4] also can provide an appropriate preposition 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.

One 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 43 the Witness role cemetery 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 internments at that site. Otherwise I simply generate an LOE report as mentioned above as that report will include all internments.

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 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 the cemetery witness to a DeathAssume* tag type can usually give appropriate date information since the tag date will be some kind of (presumed) death date. However, there is a reverse problem concerning location when linking the cemetery 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 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 the 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 for the role cemetery 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. Conversely the tags in the Burial group can only access the burial/cremation date, so the death date and 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 cemetery 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.

If any cemetery witness memo parts are added, [WM1] should not be empty so it can trigger appropriate punctuation of the output, and may often require leading punctuation to follow the name. 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] and any other witness memo part should end in an appropriate escaped puncuation (e.g. ‘\;’). [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. This data, to whatever precision is known, should be entered if not otherwise included in a transcription 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. Using the witness memo seems the most flexible and useful 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.

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 Witness role cemetery 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 internments at a cemetery, I would probably use my custom MiscFind tag linked to that cemetery pseudo person.

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 provide dates for all pseudo persons in my dataset, and its custom roles and sentences reflect its special purpose. Census people are created as of the census date, Source people as of the publication date, etc. 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, Date, Cemetery. 44 Its memo 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 should usually have a blank sort date so that the tag will sort first, with the exception of my Census people which have special sort date values for groupings. For multiple pseudo children under a pseudo parent, the order can always be assigned by the BIRTH ORDER flag 45 or by setting a non-blank sort date if that won’t cause problems. This tag type is only output on special reports associated with pseudo people.

Cremation MJH , DeathAssumeCrem MJH

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

[M4] is semi-optional qualifying text. It either qualifies the preceding cremation date (e.g. “following 9 a.m. services in the adjacent church”) and/or usually qualifies the following cremation location. Typically I enter the surrounding location’s name in [M4] instead of including it as part of the MPL location record (e.g. “at the Albert Memorial Gardens”). While many facilities may be “in” (my standard report preposition for locations) a location such as a city or village, many facilities with a crematoria are often neither “in” nor “at” an MPL location. Thus [M4] also can provide an appropriate preposition 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] 48 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.

[M4] is semi-optional text which is only used to qualify the following cremation location. Thus [M4] also can provide an appropriate preposition 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 49 the Witness role cemetery so that these tags may be linked to pseudo Location people that are cemeteries/crematoria. For details on the use of this role, see my notes about this special witness in the Burial tag type description.

Death MJH

The sentence in this standard tag type for the standard role Principal now includes the age variable [AE] 50 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. 51 [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] 52 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. 53 [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 54 , 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. 55 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 56

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 57 ) 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, NarrativeChildren MJH , FamilySectionNote

The first three tag 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. The NarrativeChildren tag type will affect the list of children in a parent’s narrative of a Journal report who is a Principal on such a tag. The tag types must be selected for inclusion in the Journal report for them to be used. They will only affect the Journal narrative and/or the list of children in the Journal report for those individuals who have such tags. If a person does not have one of these tags linked to them as a Principal, their Journal output will not be affected. I have not fully tested the Journal* tag types behaviour in TMG as I have not included them in my projects, and do not usually generate TMG Journal reports. But I do use the NarrativeChildren tag type for both Journal and Second Site output as described below. To highlight that these three tag types only affect narration, I accent them with the same colors as my Transcript tag type.

TMG Usage

The NarrativeChildren tag type is primarily intended to define sentences and custom roles to override the “Children of” and “There were no children of” heading above the automatic offspring list in the Journal report only for those selected parents who have this tag type added. It can also force a Family Section heading and/or comment even when the individual has no spouse or children, possibly to make this situation clear. This tag type also introduced the variable [:NONE:] to eliminate any header whether or not there is a list of children, and the variable [:NoBirthPlaces:] to eliminate those places on the list of children. These special sentence format codes are only recognized by TMG for use in constructing the special tag sentences for these parents in this tag type. This tag’s sentence can be defined with carriage returns to output multiple lines. The first line will appear as the heading of this section for these parents, and subsequent lines will output as a narrative note under the heading. The typical heading of the list of children in a TMG Journal report is generally indented one tab stop, so it is appropriate to construct the heading text in this tag for these parents to begin with the [:TAB:] format code. To indent the lines of the subsequent text in this tag sentence to “somewhat” line up with the automatically generated list of Primary offspring which will follow, use the LIND embedded format code. I added some custom roles to the NarrativeChildren tag type sentences for common alternatives to the automatically generated sentences.

The parents (a couple who either have a Marriage Group event or are both Primary parents for a child) must both be set as Principals to affect their joint family list and usually should be set to the same role. A couple with a Marriage Group event but no joint children will still produce a heading, by default specifying they had no children. This tag with a sentence using the special [:NONE:] variable may be desired to eliminate this “no children” heading, or to change the heading to “none known”. If there is only one Principal assigned, the tag will affect a separate list of children whose only Primary parent is this parent. If there are no such children there will be no such family list even with this tag, so this tag cannot be used to specify something about unknown offspring for the one Principal. The [PO] has been made conditional in most roles so the sentences work for such a list of one-Primary-parent children if there is only one Principal assigned to the tag. Only a tag designated as Primary for that couple will output in the Journal report, and the tag should be Primary for both Principals. The tag type must be selected for inclusion in the Journal report for it to be used, otherwise these parents with this special tag will list their children with the default heading instead of this tag’s heading, and without any following note which may have been included in the tag’s output. I generally do not select this tag type for output in non-Journal reports as for most other reports it is meaningless. 58 I usually prefer the Num Child tag type for other reports.

This tag can also be useful for including a list of non-Primary (non-biological) children within the leading note this tag produces above automatic lists of Primary offspring. When the parent/child relationship tag has not set this parent as Primary for such a child, they will not be included in the automatically produced list, so can (should?) be listed within this tag’s note. For more details about using this tag to include a list of non-Primary children see the separate section about tags used to record Adoption. I have defined the special Adoptor and several adopted* roles for the NarrativeChildren tag type with sentences which will work for both the TMG Journal report and Second Site Family Section. That description also includes examples of the memo text used to list these non-Primary children.

Second Site Usage

I also commonly use this TMG standard NarrativeChildren tag type for customization of my primary output of Second Site pages, as it can optionally be recognized by Second Site. But it operates slightly differently in Second Site output than in the TMG Journal report. First, you must enable the “Family Sections” in the Second Site configuration for Pages / Person Entry to generate an automatic list of Primary children. Next in the configuration of this Section you must specify this event tag type to be used as a “Note Event” for this Section for any parent who is a Principal to such a tag. If these options have been set and the tag sentence will produce output, Second Site will always produce a Family Section for that Principal. Contrary to TMG, the Section will be produced even when there is only one Principal but there are no one-Primary-parent children for this person. If a Principal is linked but their sentence consists of only the special header indicator and nothing else, there will be neither a heading nor a note, just the list of Primary children. And if this is the only Principal and there are no one-Primary-parent children to be listed for this person, nothing will output as a result of this tag, which is equivalent to not adding this tag at all to this person.

Second Site does not recognize TMG’s special sentence codes created only for use with this tag: [:NONE:] and [:NoBirthPlaces:] . Those codes will output as text whether in the header or the note. Thus TMG’s special sentence codes to hide them from Second Site should be used, which themselves should be hidden from TMG output. However this tag’s sentences may use Second Site-only variables, such as those to output a lifespan for either Principal: [LSP] , [LSPO] , [LSP1] , and [LSP2] . Such codes in turn should be hidden from TMG if this tag type is ever selected for output in TMG. By default the tag sentence will not replace the heading in Second Site (which is exactly backwards from its action in the TMG Journal report), but will output the text produced by the sentence as a note beneath the default heading for the Family Section in these parent’s narrative page. A special indicator of two escaped vertical bars ( \|\| ) in this tag’s sentence is recognized only by Second Site as separating the sentence text of this Note Event into header text followed by the note. This indicator will automatically cause the following note text to start on a new line. Since this indicator is only recognized by Second Site, TMG’s special sentence codes to hide them from TMG but expose them to Second Site (e.g. “ [HID:][SS:]\|\|[:SS][:HID] ”) should be used so the indicator will not output as part of the Journal heading for these parents. With this indicator feature this tag type can also be linked to selective individuals to override Second Site’s default headings of “Children of” and “Family:” above the automatic offspring list, or force a Family Section comment even where the individual has no spouse or children.

It should be obvious from my custom sentences for this tag type that I do not use some of the roles which I have included in the tag type definition and thus have not (yet) constructed them to also output in Second Site. As described above I do use this tag in both TMG and Second Site to produce a list of non-Primary children in a parent’s family list of Primary children in cases of adoption. I also use this tag type with its sentences and custom roles SubLinks or SubOneLinks to remove the term “children” from the text for the headings of the automatic list of Primary pseudo children of Pseudo people. The wording of the text will depend upon whether or not the Pseudo person is linked/married to another Pseudo person. If a Pseudo person is linked/married to another Pseudo person but there are no children, the sentence for SubLinks would still work but I prefer to use the custom role NoLinks instead. However, if later I add a child to this linkage/marriage, I will need to remember to change the roles on this tag. If the person is linked/married, I use a Date the same as the Date in the tag in the Marriage group, and a SortDate the same as the SortDate in the 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 include that information in this tag’s sentences, even though the tag in the Marriage group probably has 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.

Second Site will also recognize a tag type named exactly FamilySectionNote which is not standard in TMG and must be created as a custom tag, usually in the Other tag group. Like the NarrativeChildren tag type, the Primary parent(s) of a child would be set as Principal(s) to customize that parent’s Family Section. Normally this 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 the family section heading in TMG. In Second Site it operates exactly like the NarrativeChildren tag type, and must be specified as the Note Event in the Family Sections configuration to affect that output. By default the text which is output by its sentence also will not replace the heading, but will produce a note beneath the heading for the Family Section of these parents. However exactly like the NarrativeChildren tag type, Second Site will also recognize the special indicator of two escaped vertical bars ( \|\| ) in this tag’s sentence to separate the tag’s header text from the note text for the parent’s Family Section.

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. For this reason one of two approaches should be chosen. One approach is to use only the NarrativeChildren tag type and customize the sentence 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 TMG sentence output from Second Site, and vice versa. Alternatively one could always enter both tag types for these parents, and duplicate the information in both tag types, using NarrativeChildren for TMG and FamilySectionNote 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 companion 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.

I choose to use only the NarrativeChildren tag type, as this tag type is recognized for this special purpose in both programs. I carefully construct its sentences in two parts: one part for TMG output which is hidden from Second Site, and a second part for Second Site output hidden from TMG. While it requires constructing a complex sentence template which can handle both types of output, and duplicating some information in both parts of that sentence, I prefer using only the NarrativeChildren tag type and thus having only one tag which does both. Therefore I do not use the FamilySectionNote 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 59 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. Similar to what I have done with the Birth group tag types, I left [PARO] in the Principal sentence, but removed it from the Bride and Groom role sentences so I can easily select whether parents are mentioned. I choose to put the male as P1 and the 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

Modified the standard sentences 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.

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 to put the male as P1 and the female as P2. 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, [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. I choose to put the male as P1 and the female as P2.

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. I choose to put the male as P1 and the female as P2. If I want to say something different from each point of view, [M1] specifies the relationship in my Female Principal (or the standard Bride ) role sentence with optional Date and Location and [M2] as her comment, and [M3] specifies the relationship in my Male Principal (or the standard 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 a 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. Similar to what I have done with the Birth group tag types, I left [PARO] in the standard Principal sentence, but removed it from the Bride and Groom role sentences so I can easily select whether parents are mentioned. I choose to put the male as P1 and the female as P2. 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. 60 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. 61 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.

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] ” but imports do not have witnesses. The standard role of Witness will only output the Witness memo, where my custom witness role of mainDup will only output a duplicate of the Principal sentence with the Main Memo. I seldom include Note tags in normal reports, reserving them 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. 62 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” . 63 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 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.

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 64 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. Otherwise to ensure the tag prints, add double exclusion marks ‘--’ as the sole content of the 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. The names of most Standard relationship tag types were expanded to unabbreviated names in Version 8, and “-Bio” was changed to “-Biological”.

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

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

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

22. Due to a remaining bug, for sentences in tags in the Name group the [P] variable used at the beginning of a new paragraph in a narrative will always output the appropriate pronoun.

23. Check www.box.net.au/~johnr/rrlnames.htm

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

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

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

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

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

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

30. If the married surname includes a non-empty PreSurname field 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)”

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

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

33. from Carol Simpson on the TMG ListServ

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

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

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

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

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

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

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

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

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

43. Note to self: The cemetery role 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.

44. Note to self: The cemetery role 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.

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

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

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

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

49. Note to self: The cemetery role 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.

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

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

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

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

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

55. Note to self: The cemetery role 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.

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

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

58. The NarrativeChildren tag type is designed for output only in the Journal report due to the automatic offspring section in that report. However I need to test 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.

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

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

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

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

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

64. 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-2017. All rights reserved.