This table records cases where short names (Snames) were assigned to individuals and then the choice of name was rescinded. It contains one row for every rescinded Sname, linking the rescinded value to the Sname presently assigned to the individual.

A new row may not be inserted into BIOGRAPH with an Sname value that is an Alternate_Sname value. However, in order to accommodate cases of switched identities, ALTERNATE_SNAME rows may have Alternate_Sname values which appear in the BIOGRAPH.Sname column.

The Sname value must differ from the Alternate_Sname value.

This table lists and explains "behavior gaps": periods of time during which behavioral data (e.g. interactions, focal sampling) for an indicated group are (or are suspected to be) sparse, lacking, or simply lower than normal, for a known reason. The "known reason" is an important element of these gaps; periods of time where data collection happens to dip below the norm for unknown reasons are not included in this table.

Data from gap periods are not any less "valid" than data from any other times. However, when aggregating and analyzing data, the sparseness of data in a given period may affect the final results. The purpose of this table is to point out such periods and allow users to decide for themselves how to deal with them.

Reasons for gaps vary widely, so they are noted in a text column rather than with a support table of possible "gap reasons". This makes querying for reasons unwieldy, but this is by design; the table is intended to be used as a guide for thoughtful consideration^[27] of time periods where gaps in observation may be affecting analyses.

When discussed in this table, a "gap" does not necessarily mean a complete absence of data for the indicated period. It may merely refer to periods where collected data is sparser than usual. Also, a gap does not necessarily indicate that all data types are uniformly sparse. It may be that the gap only applies to a single type of data. Users should pay attention to the Gap_End_Status and Notes columns for details about which data types are affected.

Identification of a gap is done by a data manager. The system is not involved with this process, and does not handle data from gap periods differently than data from any other time periods. Those kinds of judgments are left for the user to make.

A group may have overlapping behavior gaps; it's possible for more than one factor to affect observation of a group at the same time.

A gap's Gap_End must be after its Gap_Start, or NULL. The Gap_End can only be NULL if the group's GROUPS.Cease_To_Exist is NULL. This allows for recording of ongoing, not-yet-completed gaps.

A gap's Gap_End and Gap_End_Status must both be NULL or both be non-NULL.

This table records the basic biographical data on baboons. It contains one row for each baboon, including still births and fetal deaths (collectively, fetal losses), on which data have been collected. In all cases the Statdate value must not be less than the Birth value. Live animals, those with a Status of 0, must have a recorded cause of death of “not applicable”, a Dcause of 0. Live animals that have no associated CENSUS rows (absences excepted) must have a Statdate equal to their Birth date. Animals with no recorded cause of death, a Dcause of 0, must have “not applicable” as the degree of confidence in both the nature and agent of death; their DcauseNatureConfidence and DcauseAgentConfidence must both be 0.

The system will generate an error when it finds a birth date that is later than the the team's last contact with the mother -- when the Birth date is later than the mother's Statdate.^[28]

All individuals with an Sname, i.e. those that aren't fetal losses, must have a Name and will have rows in MEMBERS. Individuals with an Sname may not have their Sname removed (set to NULL).

Those rows that record data on fetal losses must maintain the following relations between their data values: the Sname, Name, Entrydate, and Entrytype values must be NULL; the Statdate must be the same as the birth date (Birth); and the Status must not be 0 (alive). Because fetal losses have no Sname they cannot have corresponding CENSUS rows and there will not be any record of their group membership in MEMBERS.

Entrydate and Entrytype can only be NULL for fetal losses--when their Sname is also NULL. Otherwise, they cannot be NULL and Entrydate must be between the individual's Birth and Statdate values, inclusive. When Entrytype is B (Birth), the Entrydate must be the individual's Birth. When Entrytype is any other value, Entrydate cannot equal Birth.

The Statdate of live individuals is derived from the CENSUS table. An actual census does not have to be taken. Any observation of an individual in a group that results in a row being added to CENSUS is sufficient, except that Absences don't count. When there are no non-absent censuses and the individual is alive, then the Statdate is the Entrydate. This column is automatically updated when CENSUS is updated to ensure that these conditions remain true. When the individual is not alive the Statdate is the date of death.

Aside from the preceding caveats, Babase does not allow data to be related with an individual when the date of the data postdates the individual's Statdate. Therefore Statdate provides a convenient way of determining the end of the time interval during which there are data on an individual, a way that is independent of whether the individual is alive or dead.

An individual's Dcause represents a specific Nature and Agent of death. When considering the associated DcauseNatureConfidence and DcauseAgentConfidence values, it is important to remember that a Dcause should be interpreted as "if Nature, then Agent". It is tempting to assume that this means that the DcauseAgentConfidence cannot be higher than the DcauseNatureConfidence, but this is not so. The DcauseAgentConfidence is assigned contingent on the associated Nature being true, so it is possible for the DcauseAgentConfidence to be higher than the DcauseNatureConfidence. For this reason, the system has no rules validating the DcauseAgentConfidence based on the DcauseNatureConfidence, nor vice versa.

Confidence in the accuracy of the estimated birth date is categorized in the Bstatus column. The estimated range of possible birth dates might not be as symmetrical around the Birth date as is implied in BSTATUSES, so the specific boundaries of this range are recorded in the EarliestBirth and LatestBirth columns.

The EarliestBirth and LatestBirth columns cannot be NULL, unless the Bstatus is 9.0 ("unknown"), in which case both EarliestBirth and LatestBirth must be NULL.

The EarliestBirth must be on or before the individual's Birth, which must be on or before the individual's LatestBirth. LatestBirth must be on or before the individual's Statdate, but only for individuals with non-absent rows in CENSUS.^[29]

The LatestBirth must be on or before the Entrydate, unless the individual's Entrytype is B (Birth). As mentioned above, when Entrytype is B, the Entrydate must equal the Birth date. In these cases, if there is any uncertainty about when the individual's "true" birth date is, the LatestBirth might legitimately be after the Birth date and therefore after the Entrydate. The LatestBirth should never be long after the Entrydate^[30], so even in these cases there are boundaries placed on LatestBirth. When Entrytype is B (Birth), the LatestBirth cannot be more than 29 days^[31] after the Entrydate unless either or both of them is NULL.

The system will return a warning if the length of time between EarliestBirth and LatestBirth is more than Bstatus years^[32]. Similarly, the system will return a warning if the EarliestBirth is more than (0.5 × Bstatus) years before the Birth date, and another if the LatestBirth is more than (0.5 × Bstatus) years after the Birth date.

It's possible for an individual's Bstatus to be "too high", based on the length of time between EarliestBirth and LatestBirth. That is, a high Bstatus could mistakenly be used for individuals whose EarliestBirth - LatestBirth range is significantly less than Bstatus years. The system will return a warning if the length of time between the EarliestBirth and LatestBirth is less than or equal to the length of time indicated by a smaller BSTATUSES.Bstatus value.

When inserting or updating data in this table, the system can use the row's Bstatus to automatically populate the EarliestBirth and LatestBirth columns, if desired. When the Bstatus is not 9.0 ("unknown"):

While the UNIQUE_INDIVS table contains a larger list of all individuals across multiple populations, this table is the primary authority for the "main" population. When rows are inserted or deleted in this table, related rows are automatically inserted or deleted in UNIQUE_INDIVS with IndivId = the Bioid, and PopId = 1. Individuals in the main population cannot be added to UNIQUE_INDIVS before being added to this table.

The population census table. Aside from the BIOGRAPH.Matgrp column, this table is the origin of all information regarding group membership. This table holds all the field census data and any information regarding group membership that is recorded in the field demography notes. It contains one row per animal per group per day censused. There is an additional row per individual per demography note for those days when there is a demography note regarding the individual and group but no census of the group. (See DEMOG.)

The system will report individuals who are first censused in a group other than their maternal group (BIOGRAPH.Matgrp). The exceptions to this are when the maternal group is the unknown group or that first census row records an absence.

The system will report individuals with a BIOGRAPH.Sname that do not have any related (non-absent) CENSUS rows.

The Date must be between the Grp's related GROUPS.Start and Cease_To_Exist, inclusive, with one exception. Rows indicating absences — rows whose Status is A — may occur outside of the date range for a group's lifetime. These may sometimes be needed during fission/fusion periods to manually prevent an individual from being interpolated into a group that no longer exists or doesn't yet exist. However, a need for such absences is rare, so the system will report a warning for any "absent" censuses before the Grp's Start or after its Cease_To_Exist, exclusive.

The system will report a warning when CENSUS rows have a Status of C or D and a Date before the individual's LatestBirth, and another warning if before the individual's Entrydate.

As noted in the MEMBERS documentation, Babase does not allow an individual to be in more than one group on a given day.

Ideally, the original field census data sheets could be recovered from CENSUS, but there are several situations where that is not possible:

First, a datum is lost when an individual is actually censused in two groups on the same day because of movement between groups and the timing of the censuses.^[37] In this situation a decision should be made as to which group CENSUS should record the individual's presence on that day. A demography note should then be added to DEMOG, with text that notes the individual's presence in the second group. This results, technically, in all of the information from both censuses, or other location information, being entered into the database. However, it should be remembered that, because the information regarding the second census is in textual form, it is not readily available to automated tools.

Second, it may be necessary during group fissions and fusions to record a different Grp than what was actually recorded because it is usally not clear in real time that a fission/fusion has begun. There is necessarily a lag between when a change can be seen retroactively and when the field notebooks are actually updated to reflect the existence of the newly-formed group(s). For fusions it is important to construct group membership in Babase carefully, for the sake of maintaining group residency. If an individual is a resident of one parent group and is censused in another, the residency algorithm recognizes the other parent group as an entirely different group. That is, it does not recognize that the groups will soon be related. To prevent a loss of residency due to an apparent group change, censuses in the other parent group(s) should be recorded with the daughter group as the Grp whenever at least some of both parent groups are together.

Third, some CENSUS rows are derived from analyses of historical data and employ MEMBERS-style rows where group members generally have a row on every date of a given month that they were present, rather than just those dates when censuses were performed. See the Status column for details.

This table records the dates of first consortship for males; this is a maturational milestone in males that we have analyzed in several contexts. It contains one and only one row for every individual for which there is a recorded first consortship. Individuals who have not yet consorted, or individuals that have consorted but whose first consortship date is not known, do not appear in the table.

When there is a row in this table there must be a sexual maturity date in MATUREDATES, and the consortship date must be later than the sexual maturity date. The Consorted date cannot be before the individual's Entrydate, nor after the individual's Statdate. The individual must be at least 5 years of age on his Consorted date. The system will report a warning if the individual is 12 or more years of age on his Consorted date.

This table holds the text that records group membership information not written on the regular field census sheets, especially that from the field demography notes. DEMOG provides a means of notating CENSUS rows, and thus facilitates management of additional “free form” CENSUS rows, rows that do not directly correspond with the field census sheets.^[42] Thus, in conjunction with these corresponding CENSUS rows, the DEMOG rows capture group membership information that otherwise would not appear in the CENSUS table.

DEMOG contains one and only one row for every individual for every date for every group where the individual was noted present in free form textual field notes or other miscellaneous sources. The DEMOG row holds textual information. There is always exactly one corresponding CENSUS row, which holds the corresponding group membership information in the usual coded and structured form. (Note that only some CENSUS rows will have DEMOG rows; CENSUS rows that originate entirely in the regular censuses of groups will not, in general, have an associated DEMOG row). A single field note referring to more than one individual must appear in DEMOG as two (or more) separate rows, one row per individual. Multiple field notes pertaining to a single individual on a single date must be combined into one piece of text and entered in a single DEMOG row. (See the Protocol for Data Management: Amboseli Baboon Project for structure of the demography data as entered by the operator.)

Adding or removing DEMOG rows automatically updates the CENSUS.Status column of the corresponding CENSUS row.

This table records dates of dispersal for males (females do not disperse and do not appear in this table). It contains one and only one row for every male who has a known date of dispersed from the study groups. Males who have not yet dispersed do not have a row in this table. Only males can have rows on this table.

The system will report a warning when there is a row in this table and there is no sexual maturity date in MATUREDATES. The Dispersed date must be on or after the individual's Entrydate. The Dispersed date cannot be after the individual's Statdate when the individual is not alive (when BIOGRAPH.Status is not 0). When the individual is alive the Dispersed date may only be after the Statdate when the individual has been censused absent (CENSUS.Status is A) in the group^[44] and the Dispersed date is not after the earliest such post-Statdate census date.

The system will returning a warning when the Dispersed date is before his LatestBirth.

This table contains one row for every group on which there is some recorded information. This includes not only the study groups and non-study groups, but also temporary daughter groups and the special group “Unknown”^[45](See the Protocol for Data Management: Amboseli Baboon Project for when to use this special group.) When a daughter group becomes a regular group (after a fission or fusion is complete), the new group should be given a Permanent date to indicate that it is now a permanent group (Permanent is not NULL). Any “old” daughter groups that did not become permanent should be left in GROUPS to support the daughter grouping membership history.

Every reference to a group elsewhere in the Babase system corresponds to a Gid of one of the records in this table. Temporary groups (those with Permanent of NULL) must have a non-NULL> From_group value. Permanent groups must not have a Permanent value that is earlier than their Start value. Permanent groups may or may not have a NULL From_group value.

Note that there is no particular reason to remove from GROUPS those daughter groups that exist for only a short time during group fission. Those sorts of groups can remain temporary forever.

Neither a GROUPS row's From_group value nor its To_group value may be the same as its Gid value.

A group's Permanent and From_group cannot both be NULL. But both can be non-NULL.

The Cease_To_Exist value must be NULL or greater than the Start value. The Study_Grp value must be NULL or must not be less than the Start value. When the Cease_To_Exist and the Study_Grp value are both non-NULL the Study_Grp value must not be after the Cease_To_Exist value.

The Cease_To_Exist value must also be greater than or equal to all daughter groups' Start values.

The Last_Reg_Census value must be NULL or greater than the Start value. It also must be less than or equal to the group's Cease_To_Exist date, unless the Cease_To_Exist is also NULL. And Last_Reg_Census must be NULL or Study_Grp must be NULL or Last_Reg_Census must be on or after the Study_Grp date. The Last_Reg_Census must be NULL when Study_Grp is NULL.

The Cease_To_Exist must be the day preceeding the Permanent date of any daughter groups, unless the daughter group's Permanent is NULL. An important consequence is that all of a group's permanent daughter groups must have the same Permanent date.

A group that is a fusion product cannot have a fission parent -- the From_group must be NULL when the group is the result of group fusion, i.e., when the group's Gid appears in the To_group column of another group. ^[46]

The One_letter_code value must be unique within the time period from the group's Start date through the group's Cease_To_Exist date, inclusive of endpoints.

Individuals cannot be placed into rows in the CENSUS table before the Start date of the group, or cannot be censused in the group at all if the value of the Start column is NULL. Individuals cannot be placed into rows of the CENSUS table after the Cease_To_Exist value of the group. Note that both these restrictions apply to all CENSUS rows, even those that indicate the individual is absent from the group.

Gaps in observation of a group cannot be added to the BEHAVE_GAPS table if the Gap_Start or Gap_End are before the Start date of the group. Similarly, gaps cannot be added to BEHAVE_GAPS if the Gap_Start or Gap_End are after the Cease_To_Exist date.

This table records sexual maturity dates, the dates of menarche or testicular enlargement. It contains one and only one row for every animal who matured in a study group or who lived in a study group as a sexually mature individual, and it may occasionally contain a row for a male who was known to mature but who did not live in a study group. Individuals who have not yet matured do not have a row in this table. All sexually mature individuals should have a row in this table. Entry into sexual maturity is not always an obvious or definite event^[51], especially for males, so the Matured may be recorded as the first of the month in which the individual entered maturity.

There are restrictions on when an individual may become mature. The age of an individual at sexual maturity (Matured) must be at least 1016 days. This is about 2.7 years of age. The system will issue a warning when the sexual maturity occurs on or before the 3rd birthday. Individuals with a Mstatus of O (On) must be mature before 2922 days of age (8 years). The system will issue a warning when the sexual maturity occurs on or after the 7th birthday. An individual's sexual maturity date must be on or before his Statdate.

Some maturity dates are based on irregular observations of individuals before the long-term study began, or before the individuals entered an "official" study group. Either way, these individuals' Matured dates may be long before their Entrydate. Because of this, the system will allow but issue a warning when the month of the maturity date is earlier than the month of the individual's entry into the study population (their Entrydate).

For females, when Mstatus is O (On) Matured must be the first T date recorded in the female's sexual cycling data in the CYCPOINTS table. When Mstatus is not O Matured may not be after the first Tdate.

This table records dates individuals first attained adult rank. It allows one and only one row for every individual who has attained adult rank. Individuals who have not yet obtained adult rank do not have a row in this table.

The system will report a warning when an individual has a rank (in RANKS) before their Ranked date that is higher (where 1 is highest) than another individual who has already attained adult rank.

When there is a row in this table there must be a sexual maturity date in MATUREDATES. When MATUREDATES.Mstatus is O (On) then the rank attainment date must be later than the sexual maturity date. Otherwise, the rank attainment date must not be before the sexual maturity date. The Ranked date cannot be after the individual's Statdate. All individuals must be 5 or more years of age on their rank attainment date. Individuals with a Rstatus of O (On) must be less than 12 years of age on their rank attainment date. The system will report a warning for any males over 8.5 (exclusive) that have not yet attained adult rank.

It is possible that an individual will be known to have attained rank in a non-study group before they entered the study population (their Entrydate). Because of this, the system will allow but issue a warning if an individual's Ranked is before the first of the month of his Entrydate.