TMG™ Non-Primary Children ©MJH

Modified July 28, 2020 4:30 pm
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

TMG was designed with a focus on recording a family’s biological/genetic relationships and events. By default setting a child’s Relationship tag to a parent as Primary implies to TMG that this parent is a biological/genetic parent, whatever the label of that TMG Relationship tag type. However, many of TMG’s features can be used with customization to reflect other (usually non-Primary) parent/child types of non-biological relationships, such as Adopted children, Step children, and even a hierarchical relationship of pseudo people. This chapter discusses several customization approaches to documenting such non-standard non-Primary relationships. These include several custom tag types with custom roles and sentences, as well as customized use of standard tag types and features.

In Second Site configuration Data // People can specify conditions for individuals who are in the TMG project but are to be excluded when making the site. If the conditions are set to not show the name of an excluded parent or child, Second Site will automatically exclude any mention of them as a parent or child. However if a variable in a sentence template is used to reference an excluded person, and that variable is not conditional, the sentence template will output that clause with that variable but with the appropriate “missing” person text for the variable. In Second Site that text is defined in Strings // People Strings. As people with sensitive non-biological relationships are likely candidates for being excluded in Second Site, sentence template clauses with variables referencing such sensitive people should probably be conditional to avoid even indicating there is such a person by such a “missing” statement. In all of my custom sentence templates which reference non-Primary children within the sentence template, all but the first are intentionally conditional. However if a split memo variable is included in a sentence template, person variables could be entered in the memo part. When entered in a memo part such variables must be unconditional, since all variables in a memo must be unconditional. If the person is currently exclude, don’t enter a variable for them in that one tag’s memo. If such variables of excluded people are included in memo parts, the “missing” person text will be output.

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

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.1 Over time Second Site has 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, or only one.

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

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

The two person approach intends to focus “equally” on both lineages, but by its nature links the person’s offspring to the adopted lineage which is their surname. It often makes it harder for the offspring to trace back to their biological lineage, but facilitates viewing the events in the life of the adopted “person” as “beginning” with adoption and connected to the adopted lineage. It also makes it harder to trace forward from the biological ancestors to the offspring of the adopted person, but facilitates viewing the events in the life of the birth “person” and this line as “ending” with adoption. An extreme example of the two person approach would involve two separate datasets, one for each “person” and lineage, where each dataset really contains a one person approach. As in the true one-person approach, Second Site’s options to output non-Primary parent relationships as well as both programs ability to use an “FS Note Event” tag to customize a Family Section heading to output a list of adopted children 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/braces2) 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. As mentioned above, if an individual’s existence is sensitive any variables referencing that individual should be only within the sentence template itself and should be conditional.

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

If a new birth certificate is filed with the new name, this event can be documented with my custom BirthRec tag type (in the Other group, not in the Birth group) and using the name from the Name-Adopted tag. Finally, the child is linked to both sets of parents with the appropriate relationship tag types (usually “*-Biological/*-Bio” and “*-Adopted/*-Ado”), with those tags for the appropriate parents (typically biological) marked Primary. However, by including the Parent Section in the Second Site configuration for Pages / Person Entry, and ensuring that Non-Primary parents are not omitted on the Data / Database configuration, the “other” set of parents will be included in the Second Site child’s list of parents. In all cases one should set this one person’s standard ADOPTED Flag to the value ‘Y’.

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

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

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

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

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

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

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

While I do not use the deactivated standard tag type Adoption, the tag types I use for recording the various types of invormation concerning 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 tag type suffix, 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 markers4 and/or add roles that limited what printed. As mentioned above if an individual’s very existence is sensitive, any variables referencing that individual should be within the sentence template itself and should be conditional.

As TMG assumes any parent/child relationship set as Primary is a biological/genetic relationship, I think any known link of a parent to an adopted child should be set as non-Primary.

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

This custom event tag type is used as a reminder and marker for a child known to be adopted but with little known adoption 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.

These two main tag types (AdoptGive and Adopting) for these two 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”5 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 events as separate tags allows for the typical passage of time between these two events, where each may even occur in separate locations. Further it decouples the two events thereby not implying both occur, as the children may be adopted as a result of being orphaned rather than due to a release of parental rights.

This custom tag type records the first of the adoption events, when parents give up children for adoption.

This custom tag type is used for the second of the adoption events, when parents adopt children.

These three custom tags types are used as reminders to indicate that some specific data about adoption events is missing and needs to be found. Each of these *Find tag types can easily be converted to their respective event tag type when that documentation is found.

Several other types of data often associated with adoption need appropriate tag types to record that information. Often these can be more general and/or standard tag types.

This custom tag for recording various types of birth records can be used for a new legal birth record using the adopted name

These Name tag types allow selecting the appropriate name for each person’s event tag. I usually set Name-Birth as the Primary name, but also give it a Sort Date associated with the birth in case I desire to switch which Name tag is Primary. Alternatively Name-Adopted should have a Sort Date value to sort after the Adopting event tag for this name-change sentence to make sense in the child’s narrative.

This custom tag type is added when using the two dataset person approach which separately records the events of the adoptee before and after adoption in two separate dataset “people”. This tag links these two “persons” to facilitate changing focus to the other in either TMG or Second Site.

This very special standard tag type can be customized to list non-Primary adopted children of a “parent” in the Family Section of reports. It is one of two FS Note Events. As described more fully in the discussion of these Family Sections, this tag type is designed to replace the heading of a parent’s automatic Family Section which lists their Primary children in a TMG Journal report. It can also replace the heading of a parent’s automatic Family Section of their Primary children in a Second Site Person page. By default non-Primary children are not automatically output in these Family Sections by either software. However customized non-standard usage of this tag can manually insert a list of such non-Primary adopted children in the replacement header. Such a list could be caused to output in a Family Section even if symmetric equivalent non-Primary *-Ado relationship tags are not entered for this parent/child, although I try to maintain that symmetry. TMG (and optionally Second Site) automatically controls:

This special tag type only gives the user control of what text, such as containing a list of adopted non-Primary children, will replace the automatic heading. In the case of Second Site this tag’s Sort Date can also affect the order of this Family Section among a parent’s multiple Family Sections.

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

The use of this standard tag type for this special custom purpose required defining several custom roles. For further explanations of these Principal and Witness roles and which should be used when, see the description below of the NarrativeChildren tag type and the section within that description explaining manually inserting a list of non-Primary children using this tag type.

The following tag types provide a custom way to enter most of the information about any kind of adoption event.

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.

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.

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.

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

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

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.

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.

The output of Family Sections in both TMG and Second Site optionally can be controlled somewhat by a standard NarrativeChildren tag. The output of Family Sections only in Second Site can alternatively optionally be controlled somewhat by a custom FamilySectionNote tag. The custom FamilySectionNote used by Second Site has no special meaning to TMG and is treated by TMG like any other custom event tag. As such it should normally not be selected for inclusion in any TMG reports. When discussing the effect of either/both of these tag types, especially in Second Site, I will refer to an “FS Note Event”6 as a term to include both tag types. As of Second Site Version 7.01 these FS Note Events also can affect the sort order of a Family Section among other Family Sections for this Subject (but only in Second Site output).

An FS Note Event only gives the user control of what text will replace the automatic heading. Family Sections will automatically be produced for a Subject person both in a TMG Journal report and optionally in the Second Site Pages / Person Entry / Family Sections if that program can identify a “Family” under this Subject. There will be separate two-Principal Family Sections in both programs output for the Subject for each unique spouse associated with a Family, and an additional one-Principal Family Section if this Subject is the sole parent of a Family. A “spouse” of the Subject person is identified by being the other Principal of a Primary Marriage Group tag, and/or by being the other Primary Parent of a child. Prior to Version 7 of Second Site, a Family Section was only output automatically by either software if there are children linked as Primary parents either only to the sole Principal or to both of the two Principals of this tag, or there is a tag in the Marriage group with its one or two Principals exactly matching the one or two Principals of this tag. As of Second Site Version 7 an FS Note Event can be used to output a Family Section even if there otherwise would not be one.

The order of a Family Section among multiple Family Sections is determined differently by the final Version 9.05 of TMG, and by Second Site Version 7.01, versus earlier versions. The order is controlled by the Sort Dates of various tags which include:

• the earliest Sort Date of a Primary Birth Group tag of any child in this Family,

Whether or not any or all of the Sort Dates of these tags are blank may affect the sort order. Also whether the tag type of the Primary Marriage Group tag, is selected or not for the TMG Journal report, or included or not in the Second Site site, may affect the sort order of the Family Section. Finally, either the spouse or any children in a Family can be excluded from a Second Site site based on Data / People options. If a person is excluded, the Sort Date from the Marriage Group tag of the excluded spouse, and/or the Sort Date from an excluded child’s Birth Group tag might be ignored and thereby affect the order. I believe I have tested all of the nearly 200 possible combinations of these variables which can affect the sort order both in the final version of TMG, and in both Version 6 and Version 7.01 of Second Site.

In the final Version 9.05 of TMG a NarrativeChildren tag never affects the sort order of its Family Section. Also the existence alone of a NarrativeChildren tag will not produce a TMG Family Section based on the Principal(s) as the parent(s). If the Primary Marriage Group tag for the Family is a tag type which is not selected for inclusion in the Journal Report, TMG will behave as if that tag did not exist. If there is both no Marriage Group tag (possibly due to that tag type not being selected for the report) nor any Primary children for this Family, the Family does not exist and a Family Section will not output. This is the reason I created the custom Marr Dummy tag type to force a TMG Family Section in these circumstances.

The sort order of a TMG Family Section is first controlled by the Sort Date of this person’s Primary Marriage Group tag for this Family regardless of children’s birth dates. If this Marriage Group tag’s Sort Date is blank the Family Section will sort first7 regardless of any of the birth Sort Dates for children of this Family. If there is no Primary Marriage Group tag for this Family (possibly due to that tag type not being selected for the report) or the earliest non-blank Sort Date of a Primary Birth Group tag of any child in this Family is earlier than the non-blank Marriage Group Sort Date, that earliest non-blank Birth Sort Date will control this Family Section’s order. If a child in this Family has no Primary Birth Group tag TMG will operate as if it had a birth tag with a blank Sort Date. Note that a blank Birth Sort Date is not considered earlier by TMG than the non-blank Marriage Group Sort Date, so will not cause the Section to sort first. If all the Sort Dates of all controlling tags for this Family are blank even though the Date fields of these tags may be non-blank, the Family Section will sort first.

As of Second Site version 7 a rare bug8 associated with these tag types was fixed, and in version 7.01 the affect of FS Note Events on the order of the Family Sections (in my opinion) was greatly improved. Just as these special tag types were designed to control the default headers of Family Sections, the Sort Date of the FS Note Events now also can control the order of that Family Section among multiple Families. If the FS Note Event’s Sort Date is non-blank, that date will control the sort order of this Family Section regardless of the Sort Date of the Primary Marriage Group tag and/or the Sort Dates of the Primary Birth Group tags of any children in this Family.

To affect the Family Section the tag type must be selected as the FS Note Event for this purpose in the Second Site configuration for Pages / Person Entry / Family Sections, and a Primary tag of that tag type must exist with the Principal(s) for that Family. If the tag type is selected as the FS Note Event it will affect the Family Section whether or not that tag type is selected for inclusion in the site in the Data / Database tag list.

Either the “spouse” (as defined above), or any children in this Family, can be excluded from the site due to Second Site Data / People options. So long as there is an FS Note Event, or the spouse is included, or at least one child is included in the site for this Family, a Family Section will output. If a Family Section will output it will be sorted as if the spouse and all children were included and their Marriage/Birth Group Sort Dates were available to control that sort order of the Section. But the excluded people may not be listed in the Section depending upon option settings thereby making the cause of the sort order unclear. If there is no FS Note Event, and the spouse and all children of this Family are excluded, then this Family Section will not output. If the Primary Marriage Group tag for the Family is a tag type which is not selected for inclusion in the site, Second Site will behave as if that tag did not exist and its Sort Date will not control the Section’s order. Further if that Marriage Group tag was the only identification of this Family, a Family Section now will not output. If a child in this Family has no Primary Birth Group tag, the child will still be recognized as in the Family due to its Relationship tag(s) and Second Site will operate as if their birth Sort Date was blank.

As noted above if there is a Primary tag for this Family of the type selected as the FS Note Event, and its Sort Date is non-blank, that date will override the default sort order and will control the sort order of this Family Section regardless of the Marriage Group or any Birth Group dates of this Family. If there is no FS Note Event tag for this Family or its Sort Date is blank, the non-blank Sort Date from the Primary tag in the Marriage Group for this Family will control the sort order regardless of the Sort Dates for any children. If neither an FS Note Event tag with a non-blank Sort Date nor a Marriage Group tag with a non-blank Sort Date exists (possibly due to that Marriage Group tag type not being selected for inclusion in the site), the earliest non-blank birth Sort Date for any child in the Family will control the sort order. If all Sort Dates of all controlling tags for the Family Section are blank even though the Date fields of any of these tags may be non-blank, the Family Section will appear first.9

Second Site Version 6 and prior had a rare bug10 and sort order issues associated with these tag types, so I strongly recommend upgrading to Version 7.01 or later. For historical purposes note that with these earlier versions the Sort Date of a Primary tag for this Family of the type selected as the FS Note Event is never used to control the sort order of the Family Section. Further a Family with an FS Note Event alone but with no Primary Marriage Group tag nor children will not produce a Family Section.

Either the spouse or any children in a Family can be excluded from the site due to Second Site Data / People options. So long as the spouse is included, or at least one child is included, the Family Section will output. If there is only an FS Note Event and a Primary Marriage Group tag (no children) and the spouse is excluded, a Family Section will not output since an FS Note Event alone will not produce a Family Section. If a Family Section will output it will be sorted as if the spouse and all children were included and their Marriage/Birth Group Sort Dates were available to control that sort order of the Section. But the excluded people may not be listed in the Section depending upon option settings thereby making the cause of the sort order unclear. There exists the bug mentioned above where if there is an FS Note Event tag but all children and the spouse are excluded, then this Family Section may still output as a one-Principal Family, will sort as if the excluded people were included, and also may use the wrong sentence template for the heading. But the excluded people may not be listed in the Section depending upon option settings thereby making the cause of this incorrect heading and the sort order extremely unclear. If there is no FS Note Event tag and all children and the spouse are excluded, the Family Section correctly will not output.

The earliest Sort Date for any child in the Family will control the sort order of the Family Section regardless of the Sort Date of the Primary tag in the Marriage Group for this Family. If there are no children then the Sort Date of the Primary tag in the Marriage Group will control the order of this Family Section. If the controlling Sort Date for the Family Section is blank even though the Date field may be non-blank, the Family Section will sort first.11

The TMG standard NarrativeChildren tag type can affect the Family Sections in both TMG and Second Site, whereas the custom FamilySectionNote can only optionally affect the Family Sections in Second Site. To avoid contantly listing both tag types, a tag of either type which is set to affect a Family Section is generally called an “FS Note Event”.12 The purpose of such a tag is to customize the heading on a specific automatically generated Family Section of the Subject of a TMG Journal report (or optionally a Second Site Family Section). NarrativeChildren was added to TMG to override/replace/hijack the automatic headings such as “Child/Children of” and “There were no children of” above the Family Sections of a Journal report. FamilySectionNote was added in Second Site as an alternative to NarrativeChildren to only be used in Second Site. Although I choose to only use NarrativeChildren tags to replace headings of Family Sections, I carefully define this tag’s custom roles and sentences so that they will produce similar output in both Second Site and in TMG Journal reports.

Whether a NarrativeChildren tag can replace the heading of a Family Section and thereby include a list of non-Primary adopted children depends, as discussed in the overview of the Family Section, mainly on whether an automatically generated Family Section would be output for the specific Principal(s) assigned to this FS Note Event tag. If a Family Section is not automatically generated by either program, then a “dummy” Family Section can be caused to output in either program in order to output the replacement header of this tag. This can be done in any version of these programs which include the standard NarrativeChildren tag type by using a custom Marr Dummy tag13 with Principal(s) exactly matching the Principal(s) of the NarrativeChildren tag. If the Family Section replacement heading will include a list of Primary children, the normal heading text to be above the list of those children to follow also must be included in this FS Note Event tag’s custom sentence template as the entire normal heading is generally replaced.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

While custom roles and sentences can be defined, custom tag types with different tag names will not work, as only these two exactly named tag types are recognized by the two programs for this very special purpose. One cannot define a tag type named “NarrativeChildrenSens” containing strictly sensitive data which then might be not selected in TMG reports and Second Site. (One could define such a tag type, and manually change some tags to this type to temporarily exclude those tags from affecting the Family Section, while being sure to not select that tag type so they don’t output as narrative. But this probably would not be worth the effort.) Thus any sensitive data associated with a Family Section should use sensitivity or exclusion markers rather than alternative tag types.

TMG (and optionally Second Site) automatically controls where the text of an FS Note Event tag will output within its Family Section, whether a Family Section will output in these reports, and which Family Section heading will be hijacked/replaced. In TMG this tag type only gives the user control of what text will replace the automatic heading. As mentioned in the overview above, in the case of Second Site Version 7.01 and later this tag’s Sort Date can also affect the order of its Family Section among a Subject’s multiple Family Sections.

Where the custom text from an FS Note Event tag will output is for it to be part of or replace the heading of an automatic Family Section heading. Thus without an appropriate matching Family Section being automatically produced there is no place in the narrative to output this text.

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

Whether the FS Note Event tag will output also depends on whether an automatically generated Family Section would be output for the Subject of the report or person page. As mentioned in the overview above, there will be separate two-Principal Family Sections in both programs output for the Subject for each unique spouse associated with a Family, and an additional one-Principal Family Section if this Subject is the sole parent of a Family. A “spouse” of the Subject person is identified by being the other Principal of a Primary Marriage Group tag, and/or by being the other Primary Parent of a child.

Which Family Section heading will be affected/hijacked in the Subject’s TMG Journal report narrative, or the Second Site Person Page, depends on the Principal(s) assigned to the FS Note Event tag. There can be multiple Family Sections for this Subject. The two Principals assigned to the tag (the Subject and a “spouse” as described in the overview) must match an automatically generated two-Principal Family Section for this Subject, or this Subject as the sole Principal assigned to the tag will match an automatically generated one-Principal Family Section.

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

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

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

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

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

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

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

If heading and/or text is still desired to be output by a NarrativeChildren tag in a separate Family Section when TMG would not automatically output a Section for the desired one or two Principals (no Primary children and no Marriage group tag), a “dummy” Family Section can be forced to exist in TMG. A tag in the Marriage group can be added (usually my custom Marr Dummy tag type)16 with matching one or two Principal, usually producing no tag output. Since there are no matching Primary children the Family Section would by default produce a “no children of” heading. Then the NarrativeChildren tag with matching Principal(s) can completely replace that section’s default heading with the desired custom output. Such a dummy Marriage group tag is not required for Second Site since an FS Note Event tag will produce a Family Section for the tag’s Principal(s) even if there is no matching spouse or children. But if the Marriage group tag produces no narrative output, the presence of such a tag with the matching FS Note Event tag will do no harm in Second Site.

As mentioned in the overview above, Second Site recognizes an additional custom tag type as an FS Note Event named exactly FamilySectionNote. It can be optionally set as an equivalent alternative to using the NarrativeChildren tag type by specifying it as the FS Note Event to be used in the Second Site Family Sections configuration. This alternative tag type is not standard in TMG, and must be created as a custom tag type (usually in the Other tag group). If selected as the alternative, where, whether, which, and what this tag will output works basically the same in Second Site as the NarrativeChildren tag would when selected as the FS Note Event in Second Site. Normally this alternative tag type should not be selected for output in any TMG reports as this tag type is only meaningful in Second Site and will not affect any Family Section heading in TMG. Neither event type has to be included in the Second Site Database.Tags list, but the desired type must be set as the FS Note Event and its tags must be Primary for the Subject.

I commonly use the TMG standard NarrativeChildren tag type for customization of my primary output of Second Site pages, as it can optionally be recognized by both TMG and Second Site. However both of the two tag types recognized by Second Site as an FS Note Event operate somewhat differently in Second Site output than an FS Note Event does in the TMG Journal report. And as described in the section above about sort order for multiple Family Sections, whether a Family Section will output in Second Site and where it will sort may differ from TMG and between Second Site Version 7.01 and earlier versions.

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

Whether the tag will output also differs depending upon version. In Second Site Version 6 a Family with an FS Note Event alone but with no Primary Marriage Group tag nor children will not produce a Family Section. However, in Version 7 it will. If the Second Site options have been set and the tag sentence will output some text, Second Site will create a Family Section for this tag’s replacement heading for the tag’s one or two Principals if there is not a matching one or two Principal Family Section whose heading can be hijacked. Thus if there are two Principals for the FS Note Event tag, a two-Principal Family Section will be produced by this tag even when a two-Principal Family Section would not exist for these Principals as they are not the two Primary parents of any children nor have a Marriage Group event together. Also a one-Principal Family Section will be produced by this tag even when a one-Principal Family Section would not exist for this Principal as this Principal is neither the sole Primary parent of any children nor has a Marriage Group event without a second Principal. (Thus the “trick” mentioned above of adding my custom Marr Dummy tag type17 with appropriate Principal(s) for TMG to create an appropriate Family Section whose heading can be replaced is not needed with Second Site, but won’t do any harm if that Marriage Group tag will produce no narrative output.) Further, as of Second Site Version 7 a Primary FS Note Event for a Subject will always appear, even if the “spouse” is excluded from the site. (As described above, due to the bug in Version 6 it might still output but using the wrong sentence template for the heading.) If the spouse cannot be shown, Second Site will omit the spouse from the tag before constructing the output. A conditional reference to the other Principal will yield no output for that Principal’s name. An unconditional reference to the other Principal will yield the standard “an unknown person” text.

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

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

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

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

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

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

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

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

This usage primarily involves custom roles for the “parents” as Principals on the tag to change the heading on the Family Section to something other than “children”. Some pseudo people may also have non-Primary “children” and this tag is used to include them in the heading of a Family Section.

One set of custom usage of the NarrativeChildren tag is with my custom roles SubLinks or SubOneLinks and NoLinks intended to hijack the heading of an automatic one or two Principal Family Section for Pseudo people Principals which may include a list Primary pseudo children. As these are not really “children” I prefer to change the heading. If it is a two-Principals Family Section I will invariably have some tag with this Principal pair in the Marriage group, like a Src Link tag, whether or not they have pseudo children. If it is a one-Principal Family Section I make a point to have some tag in the Marriage group, often the Marr Dummy tag so output is equivalent in both TMG and Second Site. The intent of these three roles is to replace the inappropriate term “children” in the default headings with a phrase mentioning subordinate entities.

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

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

I use a Date in the NarrativeChildren tag the same as the Date in the tag in the Marriage group (such as the Src Link tag when “married” to a pseudo Source person), and a SortDate the same as the SortDate in that tag in the Marriage group with a trailing ‘?’ to make it sort after the Marriage group tag. In some cases the SortDate is intentionally irregular (e.g. a locale name with a Src Link to a pseudo Location person) and should still be used with the trailing question mark. I have found no value to including a Location as part of this tag as I don’t output that information in this tag’s sentences, even though the tag in the Marriage group may have a Location. While one could (and does) try to be consistent to have the Male Principal of a couple always P1, with this tag’s custom sentences there is no special requirement for this.

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

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

The following custom Principal roles are used for various relationships of the parent to their non-Primary children. In addition custom Witness roles have been defined to both list and link to the non-Primary children of a parent, as well as list and link to the biological parents of those non-Primary children.

Using a NarrativeChildren tag can provide symmetry to the Second Site option to list non-Primary parents on a child’s page as a result of any non-Primary (usually non-Biological) TMG relationship tags. An FS Note Event such as a NarrativeChildren tag can hijack an automatic Family Section heading to (also) list any non-Primary children in that replacement heading on a parent’s page even if the symmetric equivalent non-Primary relationship tags are not used for output on the child’s page. Five custom Principal roles are defined for adding lists of non-Primary children to replacement headings of hijacked Family Sections: OthParent for a list with generic or multiple relationships, Adoptor(s) and AdoptorAlone for a list of just adopted children, plus StepParent and StepParentAlone for a list of just step children. For adopting or step parents which role to use of each pair to add a particular list of non-Primary children is described more fully below in listing Adopted children and listing Step children. In all cases it depends upon whether the list of non-Primary children is for one or two Principals, whether there is a matching automatic one or two Principal Family Section whose heading can be hijacked, and whether that hijacked Family Section heading will need to also include a heading above that list of Primary children. If a matching Family Section does not exist to be hijacked, then a dummy matching Principal(s) Family Section needs to be forced to exist, at least for TMG.

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

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

Although an FS Note Event tag such as a NarrativeChildren tag by design will not output Witness sentences, I defined the general Witness roles child1, child2, child3, etc. to link the non-Primary children. Making these links provides variables to separately identify each child in split Memo parts. A variable for at least one child, usually using the child1 role, must be identified in the first split memo part for children for the sentence templates to work properly. Since these child Witness variables are entered in the memo, as mentioned above their reference will be unconditional, although any beyond the first are optional. These childN Witness variables when used in the split memo part for that child will automatically output their name and also produce IDs or hyperlinks. I do not include carriage returns beginning or ending each split memo part as the sentence template would cause the list then to be double spaced. (See also the parent(s) Witness roles below.)

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

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

Witness roles bioParent, bioMrs, and bioMr; and parents1, parents2, parents3, etc.

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

If the Primary (usually biological) parents of the non-Primary children are not common to this entire set of non-Primary children being listed, then none of the above three special biological Witness roles should be used with any of the custom Principal roles. For this case the generic biological Witness roles of parents1, parents2, parents3, etc. were defined. Any of these generic roles can be used so that the biological parent(s) names can be output within the split memo text for that matching childN, since they will not be in the heading. Note that these parental sentence variables cannot be conditional as they are within the memo. If biological parents are not known for a child, don’t include any variable in that child’s split memo part. If two parents are assigned the same role, that role’s variable will output the names of both parents. The various Primary parents variables can be used separately in the specific split Memo part for their child. For example:

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

I first customized this FS Note Event tag type to assist in recording adopted children, as I have several such relationships in my projects. For that reason I defined two custom roles for Principal(s) in this specific case: Adoptor(s) and Adoptor(s)Alone. The Principals of this NarrativeChildren tag will be either only one parent who adopts, or the couple who adopts together to match the parent(s) of the Family Section. If only one person adopts all these children then they are the sole Principal on this tag, if both adopt this list of non-Primary children then they are both linked as Principals. Which role to use depends on whether the Principal(s) who adopt also have Primary children. If the sole Principal also has one-Parent Primary children, or the two Principals also have shared two-parent Primary children, use the role Adoptor(s) for the one or for both to ensure there is an added heading for the Primary children. Otherwise use the role Adoptor(s)Alone for the sole Principal or both Principals for only listing the adopted children. If a Family Section with matching Principal(s) to this tag’s Principal(s) does not exist to be hijacked (because there are neither Primary children nor a tag in the Marriage group for this tag’s Principal(s)), then a dummy matching Principal(s) Family Section needs to be forced to exist, at least for TMG. This can be done by using the Marr Dummy tag type20 with Principal(s) exactly matching the Principal(s) of this NarrativeChildren tag.

Although a NarrativeChildren tag will not output Witness sentences, the non-Primary parental role sentences also use the defined general Witness role variables child1, child2, child3, etc. as described above for generic Non-Primary children. At least one non-Primary adopted child must be identified, usually using the child1 role, in split memo part [M1] for the sentence templates to work properly. Since these child Witness variables are entered in the memo, as mentioned above their reference will be unconditional, although any beyond the first are optional. They can be linked using whatever name variation is appropriate to the sensitivity of the situation. The details of each child is generally entered in their own separate split Memo part. Do not include carriage returns beginning or ending each split memo part as the built-in carriage returns in the sentence template would cause the list to be double spaced.

Commonly all the adopted children have the same Primary biological parents, so the three special Witness roles bioParent, bioMrs, and bioMr as described above for linking generic biological parents can be used if this is not sensitive. The sentence template of these adopting Principal roles will output common biological parents in the heading to identify them. Otherwise if desired one of the generic biological Witness roles of parents1, parents2, parents3, etc. can be used within that childN matching split memo text as mentioned above to output the biological parent(s).

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

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

As described above for generic Non-Primary children, I also use the custom Witness roles child1, child2, child3, etc. to link the step children and separately identify each in their separate split Memo part. At least one step-child, usually using the child1 role, must be identified in split memo part [M1] for the sentence templates to work properly. Since these child Witness variables are entered in the memo, as mentioned above their reference will be unconditional, although any beyond the first are optional. Do not include carriage returns beginning or ending each split Memo part as the built-in carriage returns in the sentence template would cause the list to be double spaced. For example:

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

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

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

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

There can be cases where non-Primary children in a list have a relationship which is neither step nor adopted, or have multiple different relationships. For such circumstances I also defined the generic custom Principal role OthParent for a non-Primary parent which can be used to replace the default heading of a hijacked Family Section with up to three types of text. These three types of text are entered in split Memo parts for reference in the sentence template of this role:

• [M1] an optional leading replacement heading describing the non-Primary list,

• [M3]…[M9] narrative note(s) of a list of non-Primary children, where [M3] is unconditional and must be entered but all others are conditional,

• and [M2] an optional trailing Primary children heading for after the narrative note and before the list of Primary children which may be automatically generated for this hijacked Family Section heading.

Since all text, both headers and list, are entered in the memo, this tag type could be used for listing a set of people of any kind(s) of non-Primary relationship(s) in a person’s hijacked Family Section heading. Since all people variables are entered in the memo, as mentioned above their reference will be unconditional. If a Family Section with matching Principal(s) does not exist to be hijacked, then as mentioned above a dummy matching Principal(s) Family Section needs to be forced to exist, at least for TMG.

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

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

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

If customization is desired of Family Sections for selected parents in both TMG Journal reports and Second Site, as mentioned in the overview 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 FS Note Event in the Family Sections for the entire site. You cannot have some Family Sections use one type and others use the other. Further, as noted above there are sentence variables and indicators which TMG recognizes that Second Site does not, and vice versa. Finally only since Second Site Version 7 can this tag force a Family Section list heading when there are neither Primary children nor a matching Principal(s) tag in the Marriage group.

For these reasons one of two approaches should be chosen. One approach is to always enter both tag types for these parents, and duplicate the information but use the appropriate different codes and formatting in each tag type, using NarrativeChildren strictly for TMG and FamilySectionNote strictly for Second Site output. With this approach the NarrativeChildren tag type should be selected for output in TMG (Journal) reports only, and its sentence would be constructed for that output only. The alternative FamilySectionNote then would be set as the Second Site FS Note Event, not selected for inclusion in TMG, and its sentence would be configured for Second Site output only. Alternatively one could use only the NarrativeChildren tag type and customize the sentence template to produce appropriate output for the Family Section in both TMG and Second Site. This will require using appropriate embedded format codes to both “hide” the properly formated TMG sentence template and TMG codes from Second Site, and vice versa. As stated above, I prefer using only the one NarrativeChildren tag type and thus having only one tag to enter, with an appropriate two part template which works for both software programs.

Endnotes
1. 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. 2. Note that Second Site never outputs any data marked sensitive, there is no option to do so. 3. Note that Second Site never outputs any data marked sensitive, there is no option to do so. 4. Note that Second Site never outputs any data marked sensitive, there is no option to do so. 5. Preference set under “File >> Preferences >> Program Options >> Tag Box - Show witnessed events” 6. Not to be confused with the standard TMG NOTE tag type. 7. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates. 8. See the footnote in the description for Second Site Version 6 below. 9. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates. 10. If there was a Primary tag of the type selected as the FS Note Event where this person was the only Principal assigned, and there also is such a tag with this person and a spouse assigned as the two Principals, and the spouse is excluded from the site by People options, then the Family Section which includes the spouse will use the sentence template from that one-Principal tag for the heading instead of simply excluding the spouse’s name from the two-Principal tag sentence. 11. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates. 12. Not to be confused with the standard TMG NOTE tag type. 13. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “-<[M0]>[:NP:]”) its presence is enough to generate an Family Section in TMG so long as this tag type is included. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other Marriage Group tag should be Primary. 14. The HTML codes needed in the sentence templates of these roles are likely dependent upon the Second Site Theme chosen. The codes in the sentence templates of these roles work for my use of the “nonzero-brown” Theme using the Person Entry “Narrative” format. I have not tested it with any other Second Site configurations. 15. The NarrativeChildren tag type is designed for output only in the Journal report as part of its Family Section. However I need to test (further) which other report types will output this tag if it is (mistakenly) selected for output. So far tests show it will output in: Individual Detail. 16. Even though the sentence template for such a dummy tag in the Marriage group can be excluded from output (e.g. “-<[M0]>[:NP:]”) its presence is enough to generate a TMG Family Section for the Principal(s). This tag is only required for TMG output, but does no harm for Second Site if the output is excluded. 17. Even though the sentence template for such a dummy tag in the Marriage group can be excluded from output (e.g. “-<[M0]>[:NP:]”) its presence is enough to generate a TMG Family Section for the Principal(s). This tag is only required for TMG output, but does no harm for Second Site if the output is excluded. 18. Note to self: The NoSentence role has only been added to my Maternal project as I have not formatted for Non-Primary children in my other projects. Need to test this concept in those other projects. 19. The HTML codes needed are likely dependent upon the Second Site Theme chosen. The codes in my sentence templates for these custom roles work for my use of the “nonzero-brown” Theme using the Person Entry “Narrative” format. I have not tested the output with any other Second Site configurations. 20. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “-<[M0]>[:NP:]”) its presence is enough to generate a Family Section in TMG. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other tag should be Primary. 21. Even though the sentence template for this single-Principal tag in the Marriage group is excluded from output (e.g. “-<[M0]>[:NP:]”) its presence is enough to generate a Family Section in TMG. Further, even if there is another Marriage Group tag which has this person as the only Principal, adding this tag will cause no problems since it produces no output but that other tag should be Primary.

Endnotes

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

2. Note that Second Site never outputs any data marked sensitive, there is no option to do so.

3. Note that Second Site never outputs any data marked sensitive, there is no option to do so.

4. Note that Second Site never outputs any data marked sensitive, there is no option to do so.

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

6. Not to be confused with the standard TMG NOTE tag type.

7. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates.

8. See the footnote in the description for Second Site Version 6 below.

9. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates.

10. If there was a Primary tag of the type selected as the FS Note Event where this person was the only Principal assigned, and there also is such a tag with this person and a spouse assigned as the two Principals, and the spouse is excluded from the site by People options, then the Family Section which includes the spouse will use the sentence template from that one-Principal tag for the heading instead of simply excluding the spouse’s name from the two-Principal tag sentence.

11. As is true with all events with the same dates, if there are multiple blank Sort Date Family Sections their order is undefined though they all will be before any Family Sections with non-blank Sort Dates.

12. Not to be confused with the standard TMG NOTE tag type.

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

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

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

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

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

18. Note to self: The NoSentence role has only been added to my Maternal project as I have not formatted for Non-Primary children in my other projects. Need to test this concept in those other projects.

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

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

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

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

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

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