Events in TNG and in Gedcom

From TNG_Wiki
Jump to: navigation, search

Classic Database Attributes

In many database applications, the People table would have attributes such as

  • Name - likely broken out as Firstname, Lastname, Suffix, etc.
  • Sex
  • Date of Birth
  • Place of Birth - perhaps a text value; perhaps a link to a table of Places
  • Date of Death
  • Place of Death
  • Cause of Death
  • Occupation
  • Religious Affilitation
  • Physical Description - perhaps broken out by height, weight, etc.
  • Current Address - perhaps implemented as several address fields; perhaps as a link to a table of Addresses
  • Number of Children

and some way of representing attributes that might occur multiple times such as

  • Residences at various points in time
  • Scholastic Achievements - perhaps broken out as level, degree, school, major, etc.
  • Military Service

It is easy to observe that some of the attributes in the first list, such as Occupation and Religious Affiliation might be different at different points in time.

And in a genealogy application, there could be justification for recording events such as Date and Place of Birth more than once, as different sources might report different values, each of which needs to be considered as possibly accurate.

Events

So, Genealogy databases and the Gedcom standard represent most characteristics of a person as "Events, which are composed of these attributes (among a few others to be described later):

  • The Event Type (Birth, Death, Burial, Occupation, Residence, Education, etc.), which is represented as a "Tag", such as BIRT, DEAT, OCCU, RESI, EDUC, etc.
  • Date or Date Range
  • Place
  • Attribute Value, such as an Occupation or Religious Affiliation.
  • "Agency" - An organization such as the hospital where a birth or death occurred
  • Cause - Primarily used for cause of death

Event occurrences can be characterized as "Primary" or "Secondary". The "Primary" event is the one that is considered most important, or most likely to be true. All other occurrences of the same Event Type are "Secondary", with no formal ranking. The distinction between "Primary" and "Secondary" is most important when different Event occurrences represent different opinions about the actual value. For many Events, that distinction is meaningless.

Aside from the distinction between "Primary" and "Secondary" events, the concept of "Event" is overloaded in both Gedcom and TNG. That is, it has three meanings in Gedcom (associated with the terms Events, Attributes, and Ordinances), and two different meanings in TNG (Built-in Events and Custom Events).

Gedcom Events, Attributes, and Ordinances

In the Gedcom standard, an Individual Record (for a Person) can contain multiple occurrence of:

  1. Attributes - Characteristics that take on a particular value, such as Occupation, Religious Affiliation, Number of Children, ID Number, Social Security Number, etc.,
  2. Events - Things that happen to a person at a point in time, such as Birth, Death, Burial, Baptism, Naturalization, Retirement, and so on, and
  3. Ordinances- Special Latter-Day Saint (LDS) rituals, such as Baptism, Confirmation, Endowment, and Sealing that confer a formal status upon a person (living or dead).

There are subtle differences among Attributes, Events, and Ordinances, which will be explained below. But, practically speaking, most genealogy applications essential treat them all as what we commonly call "Events". For the time being, I'll use the term "Characteristics" to mean Attributes, Events and Ordinances.

All Characteristics can, in practice, occur multiple times for a person. But Gedcom does not provide a way to distinguish between

  • An occurrence of a characteristic that represents an actual instance of that Characteristic in real life, and
  • An occurrence that simply represents a different opinion of the data values associated with an Characteristic.

For instances, when there are multiple Birth Events in a record (with different date and/or place values), it is pretty obvious that they represent different reported values, or opinions about when and/or where the event occurred, not different instances of person's birth. And when there are multiple Residence events (with different date and/or place values), it is pretty obvious that they represent different places of residence at different times. But what about two Residence events for, say 1940, at different places? There is no formal way for event data alone to tell us whether the person moved during 1940, or whether one (or both) of the values is just wrong. In order to make that distinction, it is necessary to add free-text notes to one or more of the events.

The only real differences among the three types of Characteristic are

  1. A "value" associated with the Characteristic.
    • Attributes have an attribute value such as an occupation, a religious affiliation, an SSN, etc.
    • Events and Ordinances do not (at least formally) have such a values,
    • (Look at the example Attributes, Events, and Ordinance types just above to get a better feel for the difference).
  2. Date format
    • The date values associated with Attributes and Events can be rather free-form. They can be partial (June 1980), approximate (about 1823), relative (before 1776), a date range (1953-1971), etc.
    • Ordinance Dates are supposed to be specific calendar dates - though in practice that constraint enforced only when genealogical data is used within the LDS church, not by genealogy applications.
  3. Other subordinate data
    • Aside from the Date and Place that can be associated with any Characteristic, Attributes and Events have a set of subordinate data fields (defined a couple of paragraphs below):
    • Ordinances do not have the same subordinate values. Instead, they have an LDS-specific status and a Temple code (for the LDS Temple where the Ordinance ceremony was held.

Note that all Characteristics may have a Place Name and Date, even though some Attributes, such as Social Security Number, are never going to have a Place Name value.

The Ordinances are distinct because they are formal LDS ceremonies whose date and place are conscientiously defined and documented in the same way throughout the world. The various Gedcom Attributes and Events, however, can be documented and described in various ways, and be know or understood very well or very poorly, depending on when and where people lived (and died), how much they or their families moved, their religious and financial circumstances, and so on. In truth, some Attribute or Event tags could logically belong in either category. For example, RESI (Residence) is defined as an Attribute, even though there is no particular Attribute Value for a Residence.

'Ultimately, most genealogists and many genealogy applications do not distinguish between Attributes and Events, and may or may not treat Ordinances much differently from Attributes and Events. Generally speaking, genealogy application just have "Events"; some of which may get some special handling.

In particular, in most genealogy applications, most Events (speaking generically) are likely to have a place where an Attribute/Event Value can be stored, even if the formal Gedcom definition of that Eventtype or Tag does not provide for such a value. And the subordinate data values for Attributes and Gedcom Events are likely to be available for Ordinances, even if they are never actually populated.

Name and Sex

To Gedcom, Name and Sex are not Attributes nor Events (and certainly not Ordinances); they are specific elements of a Person record. The are specified in Gedcom files in much the same way as an event, but with fewer attributes. Their tags are. unsurprisingly, NAME and SEX

  • The Name element can occur multiple times, and in its value (the name itself), the Surname (the family name) is supposed to be enclosed in slashes so that name can be broken into three components:
      1. Surname,
      2. Given Name (first and middle names), and
      3. Suffix (Jr, Sr, M.D., etc).
    • A Name element can include a subordinate structure called the "Personal Name Structure" that may re-specify the Surname, Given Name, and Suffix, and that provides up to more name components:
      1. Name Prefix (Judge, General, Dr, etc),
      2. Nickname(s),
      3. Surname Prefix, which is defined to be things such as ('de', 'de la', 'Van', and 'Von'), but such prefixes are very frequently defined as part of the Surname.
  • Formally, Sex can occur only once.
    • As you can imagine, the Gedcom standard provides for only two sexes.
    • In practice, the Sex values of 'M' and 'F' are typically tied to the definition of Husband and Wife in a Family, so it is difficult for most genealogy applications to handle other gender identities or same-sex marriages.

TNG accepts one Name structure - that is, one name, divided into name component fields. TNG users can define (or allow) custom name events (custom events are described below) that store an alternate name, but TNG features that search for or display a person's name will only use the one as a "

Genealogy applications may or may not allow a person to have multiple NAME value. In TNG, for example, the NAME is always broken into

Family Events

So far, all Events (e.g. Attributes, Events, and Ordinances) that have been discussed apply to People (or, in Gedcom parlance, Individuals). But the same concepts apply to Families, except that Gedcom doesn't define any Family Attributes; just Family Events and Ordinances.

The generic Event EVEN

Gedcom defines an Event whose tag is "EVEN" and that can be used with People or Families to store essentially any kind of value, no matter whether there is a Gedcom Tag for that concept. The Gedcom Event/Attribute substructure has a field called "Type" which defines the descriptive of an EVEN Event. Regular tags can be though of as "Event types", as can the combination of the "EVEN" tag and an associated Type. Fairly commonly-used EVEN Event Types include:

  • Arrival - Similar to IMMI (Immigration), but applicable to locales other than countries.
  • Departure - Similar to EMMI (Emmigration)
  • Race - Gedcom defines a NATI (National or Tribal Origin) Attribute, but not Race
  • Literacy
  • Civil - Used for a variety of events that represent interactions with government.

Other Non-Standard Event Types

In addition to the generic Event "EVEN", the Gedcom standard allows data files to contain any Event tag that starts with an underscore. Fairly common example of underscore Events include:

  • _MILT - Military Service
  • _DCAUSE - Cause of death
  • _PHOTO - The "primary" photo for a person.
  • _MISN - Missionary service
  • _AKA - Also Know As
  • _EYE or EYEC - Eye Color
  • _MDCL - Medical condition

(I cannot explain why some non-standard Events are defined through the "EVEN" tag, and others through underscore-tags.)

Subordinate Event Values

These fields are defined as element of Event record by Gedcom, and are fields in Event records in TNG.

  1. Age - Meaning "Age at the time of the event"
  2. Agency - Meaning an agency or institution associated with the event. This is typically a facility, such as a hospital associated with a birth or death, or a house of worship where a marriage takes place. It could also be, for example, the employer associated with an occupation or residence event.
  3. Cause - Most commonly used for the cause of death. However, the cause of death is often simply mentioned in a note associated with the death. And some genealogy applications or individual databases have a "Cause of Death" Event type.
  4. Address - In TNG, a link to the Addresses table. A street address such as a place of residence, or even the street address of the Agency or facilty. Note that the address is tied to the event independently of the Place name.
  5. Type - A value such as 'Bond Date', 'Civil', or 'Literacy', that characterizes an Event that uses the generic Eventtype "EVEN".

Citations, Notes, and Media Objects

All Gedcom Events (speaking generically now) and TNG Events can be associated with multiple

  • Citations, which link to a Source record, and that
    • Tell where, within the Source, the information that supports the Event values can be found, and
    • Describes or quotes that information
  • Notes - Arbitrarily long free-text notes, and
  • Media Objects - Photos, Document Images, Stories, etc.

TNG Events - Built-in and Custom

TNG does not distinguish between the Gedcom concepts of Events and Attributes, though it does treat Gedcom Ordinances in a particular way, without ever using the term "Ordinance". TNG has two types of Events:

Built-in Events

As first installed, TNG saves only few types of Person Events into its database. They are known as "built-in" Events, and their Date and Place values are stored in the People tables. They are:

  • Primary Birth
  • Primary Death
  • Primary Christening (aka Alternate Birth)
  • Primary Burial
  • Primary LDS Baptism
  • Primary LDS Confirmation
  • Primary LDS Initiation
  • Primary LDS Endowment

"Primary" means the first event of that type in the Person record.

All of these Event types are, to Gedcom, formally defined as "Events", which cannot have free-text Event Values, and these Built-in Events cannot have such free-text Event Values. They are represented by specific fields in the People Table named

  • birthdate
  • birthplace
  • deathdate
  • deathplace
  • etc.

Each Date value is actually represented by two fields:

  • The free-form date value such as "20 Apr 1933", "1984", "Abt May 1960", "Bef 1776", or even "8/16/1720"
  • A formal date value that can be used in date calculations, e.g. "1933-04-20", "1984-00-00", "1960-05-00", etc. Note that missing components are represented with zeroes, and relative or approximate dates are represented as though the prefix were not there. The fieldname for the formal date value is formed from the fieldname of free-form date value, with the letters tr added (birthdatetr, birthplacetr, etc.).

Custom Events

ALL other events for a person are called "Custom Events", including

  • Secondary Event occurrences for the Built-In Events
  • The Primary and Secondary occurrences for other Event Types (i.e. Events and Attributes) defined by Gedcom
  • Event Types not defined in Gedcom

The Date and Place values for each Custom Event are stored in the TNG Events table. All Custom Events may have an Event Value, even the secondary occurrences of the Built-In Events (which cannot).

Name and Sex

Name and Sex are stored in the Person table, like Built-In Events.

Sex is simple. In both Gedcom and TNG, a person can only have one value for Sex, and, it must be M, F, or U. It is certainly possible for Sex to be defined as a Custom Eventtype, in which case, it can have a date and place.

Name is more complex.

  • In both Gedcom5.5 and 5.5.1, the Name structure can occur more than one time in an Individual record, but in TNG, there is room for only one Name.
  • The Primary Name value is always separated into name components (Given name, Lastname, Suffix, Nickname, etc).
  • Name component values supplied by a subordinate Name Structure in a imported Gedcom file will override the values calculated from the parent Name value.
  • There is no direct provision for secondary names, though the NAME tag can be defined as a custom Eventtype. But Name values entered or imported as secondary events will not be separated into components, nor considered by any TNG operations that are search for a person by name. And secondary name compoent
  • Name components (Given, Surname, Nickname, etc.) can also be defined as Custom Eventtypes in TNG, but like secondary NAME event, secondary name components will not be combined into a full name, or will any TNG operation that searches for or display a Person's name, consider these secondary components.

Family Events

In TNG, the Built-In Events for Families are:

  • Primary Marriage
  • Primary Divorce
  • Primary Sealing (LDS)

and any secondary event occurrences for these event types go in the Events table - again, given either

  • The presence of corresponding Eventtypes in the Eventtypes table, or
  • The TNG setting "accept all undefined events in a Gedcom import" (which does add those events to the Eventtypes table)

Note that a secondary Marriage event does NOT mean a Person's second marriage, but rather a second possible value for the date and place of the marriage for a family (which is defined by a "Husband" and "Wife", no matter whether they actually married)

The Generic Event EVEN

The notion of a Event Tag (or Event Type) in Gedcom is implemented in TNG as a table of Eventtypes, which must have a Tag. Most TNG tags are defined in Gedcom, but any arbitrary Tag may be defined in TNG. The handle the "EVEN" tag, a unique Eventtype is composed of three fields - tag, a field called description (the Type), and a field called type, which refers to the kind of record (primarily I for Individual or F for Family) that for which that Eventtype is valid. actually is handled by most of which are Gedcom Tags.

Other Non-Standard Event Types

As noted above, TNG does not restrict its Custom Event Types to Gedcom tags. So any common (or uncommon) underscore Tag can be defined in the TNG Eventtypes table. And if a TNG site administrator wanted to define Eventtypes such as "First Kiss" or "Batting Average", with Tag values of, say, "KISS" and "AVG", TNG will go right along.

Subordinate Event Attributes (The Event Table)

The Subordinate Event Attributes defined by Gedcom (with one exception) are stored in TNG's Events table. Events have the following fields: Events are also associated with a Tag or Eventtype. The meaning and constraints of a Tag are not defined within a Gedcom data file; they are just part of the Gedcom standard. In a genealogy application, such Gedcom standard definitions can be implemented in a database table. In TNG, the Eventtypes table is essentially equivalent to a table of Event (and Attribute) Tags. Each Event in the TNG Events table has an eventtypeID field, which is a foreign key to the Eventtypes table.

In Gedcom, there is also an Event attribute called Type, which is primarily used to define the Event type of an "EVEN" event. TNG does not implement the Type attribute as an attribute of an Event. Instead it is a attribute of an Eventtype called description (which should not be confused with the Eventtype attribute named type).

The TNG Event Table

  • eventID - The Identity key - also used as the foreign key value when other records need to link to an Event.
  • eventdate - The free-form Event date,
  • eventdatetr - The "translated", or computed form of the Event date,.
  • eventplace - The Place Name associated with the event,
  • age - the Age at the time of the event
  • agency - the agency or institution associated with the event. This is typically a facility, such as a hospital associated with a birth or death, or a house of worship where a marriage takes place. It can also be, for example, the employer associated with an occupation or residence event.
  • cause - Most commonly used for the cause of death. However, the cause of death is often simply mentioned in a note associated with the death. And some genealogy applications or individual databases have a "Cause of Death" Eventtype (which is not defined in Gedcom).
  • addressID - A foreign key to the Addresses table, where the street address associate with the event will be stored.
  • info - The Event Value; which, in TNG, is a 255-character text field called
  • gedcom - The foreign key to the Trees table, and part of the two-field composite key that links to the record (a Person, Family, or Repository) associated with the event.
  • persfamID - An overloaded foreign key field that may contain a personID, a familyID, or a repositoryID.
  • eventtypeID -
    • For Custom events, eventtypeID is a foreign key to the Eventtypes table, and
    • For Built-in Events, eventtypeIDis a Tag value (BIRT, DEAT, BURY, CHR, MARR, DIV, etc.) that identifies the Build-in event associated with the record. Note that this field is not a foreign key in this case. Either PHP code or complex Case logic in SQL code is necessary to transform that Tag value, along with the composite foreign key (gedcom,persfamID), into references to specific fields in the People or Families tables.

Links from other tables back to Events

Because of the 1-to-many relationships between Events and Notes, Events and Citations, and Events and Media Items, each of those tables (or their linking table) links to Events. The Events table does not link to those tables.

  • To link to Custom Events, the Citations, Notelinks, and Medialinks tables need only a foreign key to the Event table called eventID. (The Noteslinks table is a linking table for Notes that allows Notes to be used by multiple records in a many-to-many relationship, but the TNG application does not support many-to-many relationships with Notes, so there is actually a 1:1 relationship between Notes and Notelinks.)
  • To link to Built-In events, the other tables use
    • The composite foreign key (gedcom,persfamID) to link to the Person or Family table, and
    • the eventID field, which (for Built-In Events) contains a Tag name such as BIRT, DEAT, MARR, DIV that identifies which fields in the People or Families table contains the data for that event.

The TNG Eventtypes Table

The TNG Eventtypes table defines all allowable values for the Tag and Description (OCCU & Occupation, etc.) of Custom Events. When first installed, the Custom Events table has no Person or Family Eventtypes. The Administrator of each TNG site can either

  • Enter the Tag and Description values for all Event Types to be stored in the Events table - including the secondary instances of Built-In Events (BIRT & Birth, DEAT & Death, etc.), or
  • Tell TNG to accept previously unknown Event tags that it finds in an imported Gedcom file. The TNG software will recognize some event Tags and populate their Description.

The Eventtype table has have the following fields:

  • eventtypeID - the identity key (and the value used in foreign keys that link to Event records)
  • tag - The associated Gedcom tag, or made-up tag
  • display - The word or short phrase that is displayed with data associated with the tag, e.g. Birth, Death, Occupation, Education
  • description - The TYPE value for EVEN events. It is, for all practical purposes, the same as the display field, but defined only for EVEN tags. The tag value "EVEN" will appear multiple times in the Eventtypes table; once for each description.
  • type - I, F, or R, indicating whether the Eventtype can be associated with an Individual, Family, or Repository record.
  • keep - A flag that instructs the Gedcom Import process to keep events of this type.
  • collapse - A flag that is used by the TNG Person Profile to indicate whether all events of this type should be listed by default, or whether a placeholder that can be expanded is displayed. (A TNG configuration value determines the minimum number of events of a given type to trigger a collapse.)
  • ordernum - Can be used by the TNG Person Profile to control the order in which events are displaye

Associating People with Families

Events are not used to associate People with Families in either Gedcom or TNG. In Gedcom, the tags "FAMC" and "FAMS" (for Child and Spouse) link a person to a family as a spouse or as a child. Those tags look just like Event/Attribute tags, though they cannot have Date and Place values, but, in a Gedcom Import, those tags have to be interpreted and processed very different from Event/Attribute tags.

Event Place Names

Place Names associated with an event are typically the name of a locale (town, county, state, and/or country). Formally, Place Names are supposed to be composed of comma-separated "Jurisdiction Names" such as "Houston, Harris County, Texas, USA", "Harris County, Texas, USA", "Texas, USA", "USA", or perhaps "Houston, Texas", or "Texas". Geographic names such as "Long Island, New York" or "East Tennessee" are discourages, but, practically speaking, there is no real way to exclude geographic names, which are often all that is available.

In Gedcom, all Place names stand alone. That is, Gedcom has no concept of Place ID's nor a "List of Places".

However, TNG, like most other genealogy applications, does keep a table of Place Names, and puts all unrecognized place names in that table. TNG does not have a Place Authority; it has to accept whatever place names it is given.

(A Place Authority is a resource, either within the application or online, that is intended to supply a vast number of official "Jurisdiction Names" from around the world. Different applications that use Place Authorities are more or less strict about trying to enforce the use of standardized place names, but all have to allow non-standard names just because the place names supplied in genealogical data sources can include informal geographical names and place names that no longer exist.)

Facility names, such as the hospital where a birth or death takes place, or the house of worship or civil institution where a marriage takes place, are general not included as part of a Place Name. There is a provision for Facility Names within an Event record, however.

On the other hand, (and I have no idea why) Cemeteries, Graveyards, Mausoleums, and the like ARE generally included in Burial Place names. In fact, TNG has a provision for keeping track of cemeteries, burial plots, and gravestone photos that requires that the cemetery name be part of the Burial Place name. Burial plots and an association between gravestone photos the cemeteries are not supported by Gedcom.

Repository Events

Repositories have an Address attribute that is implemented as an addressID foreign key to the TNG Addresses table, but, in a departure from the Gedcom definition of Repositories, TNG also provides for two specific Repository Events that are stored in the Events table. Even though the Addresses table has email and phone fields, the Tag value, EMAIL and PHONE, are defined, by default, in the Eventtypes table. Although the TNG database allows a Repository Event to have a date, a place, an agency, etc., the TNG application only deals with the Event value (the info field) in Repository Events.

The existence of Repository Events means that the persfamID field in Events can really contain a personID, a familyID, or a repositoryID (actually, repoID)

See also