TNG Events and Event Types

The term "standard events" in TNG usually doesn't mean the same thing that it does in Gedcom; that is, events that are defined in the Gedcom standard. Instead, it generally means "Built-in" Events.

Built-in Events

TNG's "built-in" events are a subset of the events defined in the Gedcom standard. In TNG, "built-in" means refers to events that defined by the TNG code, and whose dates and places are stored in dedicated fields directly in TNG's People and Families tables. The built-in events can be seen clearly in the TNG People and Family edit pages.

In Person Records: Name Sex Birth Christening Death Burial Baptism (LDS) Confirmation (LDS) Initiatory(LDS) Endowment (LDS)
In Family records: Marriage Divorce Sealing (LDS)

To say that these events are stored in the People and Family tables is to say that their dates and places are stored in fields in the People and Families tables, and that those fields are specifically for those events. Note there no field is specifically "birth", "death", etc. Instead, the built-in events are represented by three fields. In the case of Birth, the fields are birthdate and birthplace and a value that is specific to TNG, a sortable date in birthdatetr.

Whether Name and Sex are truly "events" is ambiguous. They are certainly distinct from the other built-in events in that

• They have values (and Name actually consist of several values - Firstname, Nickname, Lastname, Suffix, etc.), and
• They do not have associated date and place values.

It's important here to state what an event "value" is or isn't. "Born on a mountaintop in Tennesse" and "Died with his boots on" are not values of the birth and death events. They are notes that are often represented as if they were values (maybe called something like "description" or "details") in various genealogy programs. Typical "legitimate" event values apply to a subset of the event types that are defined in TNG with the misnomer "custom" events, such as Education (where the value is a school, not a degree), Graduation (where the value is a degree), and Occupation (well, you probably get it now). Actually, in Gedcom, but not to TNG, the events that TNG treats as built-in events are allowed to have one legal value, "Y", meaning "this event occurred". The most practical way to represent that value in TNG is with the date value. Some people use "Y"; others use "Unknown". (If you import a death event with the value "Y", that value will be stored as a death note.)

Custom Events

Facts and events other than the built-in events - including secondary instances of the built-in event types - depend on the Custom Eventtypes database table. None of them are hard-coded into TNG, and their event data is stored in the Events table, where the eventtype is an attribute. In this content, an eventtype is associate with a "tag" (NAME, BIRT, OCCU, RESI, etc.). The tags themselves are not stored in the Events table. Instead, the Events table has an "eventtypeID" field that refers to the identity key of the Custom Eventtypes table, which, for each eventtype, stores (most significantly) the tags and the their display values (Name, Birth, Occupation, Residence, etc.)

Practically speaking, some Custom Eventtypes need to be defined on every TNG site. That process is described in the [#Creating_Custom_Eventtypes|Creating Custom Eventtypes]] section below.

Here is a clip from one site's Custom EventTypes search results list that is annotated with highlighting of groups of events:

The eventtypes outlined in green are the same as the built-in events, allows the database to record secondary events for those event types. Significantly The "display" value for some of these eventtypes have been contrive to flag the fact that they are secondary events. It's not particularly likely that you would want do that in your database. to be recorded. Gedcom doesn't provide for secondary Name and Sex events, though it does define an Alias eventtype. But TNG can support ANY eventtype, from Accreditation to Zoom Address, no matter whether they are defined in the Gedcom standard. All secondary events necessarily have date and place attributes, but those attributes are not required. All secondary events have a field for a value (sometimes called description, detail, or info) which is commonly populated with short notes, but really should be defined only for eventtypes such as Occupation, Graduation, and Degree that take natural values other than descriptive text. The Email and Phone events outlined in red are actually associated with Repositories rather than People or Families. These are defined as eventtypes rather than as attributes of the Repositories table so that Respositories can have more than one email address or phonenumber. The events outlined in blue represent a Gedcom artifact. One way that Gedcom accommodates non-standard events is through the standard "EVEN" (for Event) tag that takes on an arbitrary "TYPE". All of the unmarked events are TNG "Custom" events that are recorded in Event records in the TNG database. You can see that most of them are standard Gedcom events with standard Gedcom tags, but two - _DECAUSE, and _MDCL - are nonstandard.

Creating Custom Events

When TNG is installed, the EventTypes table is empty. Event Types can be entered manually, or added by processing a Gedcom file.

Entering Event Types manually

At Administration >> Custom Event Types, you'll see a table similar to the one above, and you can use the Add New tab to create additional Custom event types. Each event type has the following attributes:

• Associated With - Which type of object - Individual, Family, Source, or Repository
• Tag - The short, capitalized code used in Gedcom files. A number of tags are already defined in a drop-down list, or you may enter any tag value.
• Type - The Tag type associated with the EVEN (Event) Tag. This should be a single word.
• Display - The value to be used on Person and Family Profiles, and some other reports, to identify events of this type. This should generally be a single word.
• Other Languages - If you have defined other languages to be active on your site, you can enter display values for each of those languages.
• Display Order - A digit that groups events on the Person and Family profiles. All events with Display Order=0 are displayed before events with Display Order=1, etc.
• Event Data: Accept/Ignore - When this Event is seen in a Gedcom, should it be loaded into the database, or ignored.
• Collapse Event: Yes/No - When yes is selected, on the Person or Family Profile, when there are multiple instances of an event type (such as Residence or Census), the events will not be displayed initially. Instead, just one line with the event display string will be shown, with an arrow that the user can click on to display all instances of that event type.

Gedcom Import

At Administration >> Import/Export >> Import, where you start a Gedcom import, you may check either (or neither) of two checkboxed:

• "Import Custom Event Types Only" - The Gedcom file is read only to load the EventTypes table with event tags not already in the table. Then you can go to the Administration >> Custom Event Types screen to select new eventtypes as necessary to change their attributes, and then run the Gedcom Import again.
• "Accept Data for all new Custom Event Types" - All new event types in the Gedcom file will be added to the EventTypes table as the Gedcom is process, AND data associated with those event types will be saved in the database.

Other Considerations

1. In some TNG reports, when there is no Birth date, the primary Christening date will be used in its place (often prefixed with "chr." or some other abbreviation).
2. In some TNG reports, when there is no Death data, the primary Burial date will be used in its place (often prefixed with "bur." or some other abbreviation).
3. Because "Baptism" is a special LDS event, and LDS events are not always displayed, infant baptisms should be recorded as "Christening" events, not as "Baptisms"

See also

Events in TNG and in Gedcom
The TNG Wiki take on GEDCOM