There are events and attributes for persons and families.
Events happened at a specific point in time, e.g. birth, adoption, marriage, death.
Facts or attributes describe more permanent characteristics of a person, e.g. religion, nationality, education, title.
But this distinction is not always clear: Attributes can change over time as well.
The Edit View provides already fields for birth and death.
Further events and attributes of a person we can add via the button 'Add properties'. The selector window shows the predefined events and attributes together with short explanations. We select with a double-click and enter the data. The result is visible in the 'Events' segment. There the events can be edited or deleted.
To add even more attributes to attributes of events we right-click on an attribute and select from the Context Menu.
In some cases it might be necessary to switch to the GEDCOM mode and use the context menu → 'Add properties …'.
We can easily see the possible events and attributes in the Context Menu.
To every event and attribute we may add details like type (TYPE, see below), date, place and address (see Place specifications), cause, age of person and link to Note, Multimedia Object and Source. The easiest way is to use the context menu of the proper attribute → 'Add property …'.
For a discussion when we should store information as events and facts or as notes see How do we structure our data?.
The following doesn't list all events, but explains some special cases and cases of doubt.
The interpretation of the various GEDCOM tags for christening (BAPM, CHR, CHRA) are discussed rather adversely. Various aspects are considered like the admission to a religious community, the age of the baptized, the naming, the kind of the religious ceremony (with water) a.s.o.
In 1999 the LDS program Legacy 2.0 offered a function to convert at GEDCOM import all BAPM into CHR. Thus it seems that CHR will be the proper tag for non-LDS christening.
The EVEN tag is intended for a noteworthy happening related to an individual that cannot be expressed by predefined event types (BIRT, DEAT, …) and is qualified or grouped by a subordinate TYPE tag (see below).
The GEDCOM standard is inconsistent on this fact. It mentions two variants:
Example 1: For a person that signed a lease for land dated October 2, 1837 would be recorded in GEDCOM as:
1 EVEN 2 TYPE Land lease 2 DATE 2 OCT 1837
1 EVEN Appointed Zoning Committee Chairperson 2 TYPE Civic Appointments 2 DATE FROM JAN 1952 TO JAN 1956 2 PLAC Cove, Cache, Utah 2 AGNC Cove City Redevelopment
The FACT tag is intended for a noteworthy attribute or fact concerning an individual, a group, or an organization that cannot be expressed by predefined attribute types. In 5.5.1 it was introduced additionally to the EVEN tag, to express the semantic difference between events and attributes.
A FACT must be qualified or classified by a subordinate TYPE tag (see below).
For example, the attribute could describe a person's skills, such as woodworking,:
1 FACT Woodworking 2 TYPE Skills
This groups the fact into a generic skills attribute, and in particular this entry records the fact that this individual possessed the skill of woodworking.
A number assigned to identify a person within some significant external system. A subordinate TYPE tag must identify what kind of number is being stored.
If we want to record different marriage ceremonies, we have to create two marriage events:
The MARR tag then is subordinated with a TYPE tag with a value of e.g. 'Common Law' or 'religious':
1 MARR 2 TYPE Common Law
An address or place of residence that a family or individual resided. This tag allows to record not only an address but a time span as well.
1 RESI 2 ADDR 73 North Ashley 3 CONT Spencer, Utah UT84991 2 DATE from 1900 to 1905
A further qualification to the meaning of the associated superior tag: a short one or two word note that should be displayed any time the associated data is displayed.
This gives the user flexibility in further defining information in a compatible GEDCOM context and the reader to understand events or facts which have not been classified by a specific tag.
The value of the TYPE tag is not intended for automatic processing:
Exceptions: if there is a list of standardized values, e.g. for the name type, see Personal name, and there for the romanized type and the phonetic type.
A subordinate TYPE tag is mandatory for FACT and IDNO, for other tags it is optional.
1 EVEN 2 TYPE Awarded BSA Eagle Rank 2 DATE 1980