Group Membership and Life Events

ALTERNATE_SNAMES (Alternate Short Names)

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.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information from BIOGRAPH or other places where the animal's three-letter code appears.

This column may not be NULL and may not be 998.

Alternate_Sname (Alternate Short Name)

An Sname once associated with the individual identified in the Sname column. This column may not be empty, it must contain exactly 3 characters, it may not contain lower case letters, and it may not contain the space character. This column may not be NULL.

Name_Alternate (Alternate Name)

The name associated with the alternate sname. This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

This column may be NULL.

Notes

Notes regarding the existence of the alternate Sname. This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

This column may not be NULL.

BEHAVE_GAPS (Gaps in Behavior Observations)

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[25] 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.

Column Descriptions

BGId (Behave_Gaps Identifier)

A unique integer identifying the BEHAVE_GAPS row.

This column is automatically maintained by the database and must not be NULL.

Grp (Group)

The Gid of the group affected by this gap.

This column must contain a Gid value of a row on the GROUPS table. This column may not be NULL.

Gap_Start (Start Date of the Gap)

The date on which the gap began. This date must be between the group's GROUPS.Start and GROUPS.Cease_To_Exist, inclusive.

This column may not be NULL.

Gap_End (End Date of the Gap)

The date on which the gap ended. This date must be between the group's GROUPS. Start and GROUPS.Cease_To_Exist, inclusive.

This column may be NULL, see above.

Gap_End_Status

The reason for, or status of, the gap's end. The legal values for this column are defined by the GAP_END_STATUSES support table.

This column may be NULL, see above.

Notes (Explanatory Notes)

Text notes about the gap, especially information about the gap's cause.

This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

BIOGRAPH (Baboon Biographical Data)

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.[26]

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

Caution

The Psionload program treats an Sname value of 998 in a special fashion. 998 may not be used as an Sname value. See the Psionload documentation below for details.

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.

Caution

Living individuals, unlike dead ones, can have MEMBERS rows created by the interpolation procedure that locate the individual in a group on a date later than the individual's Statdate. For further information see: Interpolation at the Statdate.

In a like fashion, living individuals, unlike dead ones, can have CYCPOINTS rows created by automatic Mdate generation on a date later than the individual's Statdate. For further information see: Automatic Mdate Generation.

Caution

Male Dispersed dates may be after the Statdate when the individual is alive and there are subsequent censuses of the group from which the individual dispersed.

Caution

When dates are encoded as intervals to account for uncertainty in the data, as with the CYCPOINTS Edate and Ldate columns, the latter end of the interval may post-date the Statdate.

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.[27]

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[28], so even in these cases there are boundaries placed on LatestBirth. When Entrytype is B (Birth), the LatestBirth cannot be more than 29 days[29] 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[30]. 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.

Column Descriptions

Bioid (Biograph IDentifier)

A unique integer identifying the BIOGRAPH row.

Babase rarely uses this identifier; it exists for the convenience of application programs and for distinguishing individuals without Snames (fetal losses) from each other and from other individuals.[31]

This column is automatically maintained by the database, cannot be changed, and must not be NULL.

Sname (Short Name)

The short name of the individual. This is an exactly three character long name abbreviation which is used to identify the individual and so must be a unique data value. It may not contain lower case letters or spaces.

Tip

The Sname is usually, but not always, the first 3 characters of the Name.

This value appears in many other places in the system and so should not be changed without changing all the other places in the database where the abbreviation appears; really, once established, the only reason to change this column is because the short name had already been used. [32] Because this is unlikely, Babase does not allow the Sname to be changed. The Sname is always composed of capital letters and may not contain a space.[33] This column should only be NULL if the row represents a fetal loss.

Name

The name of the individual. This is a textual column used for descriptive purposes. This value must be unique when a comparison is done in a case insensitive fashion. This column should only be NULL if the row records a fetal loss. This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

Pid

The Pid value, from the PREGS table, of the individual's mother's pregnancy that ended in the birth[34]of the individual. This column may be NULL. A NULL value indicates there is no record of the individual's mother.

Caution

More than one individual may have the same Pid, as long as they were products of the same pregnancy. This occurs when twins are born into the study population.

This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

Birth

The date the pregnancy ends. For live births and for individuals whose maternity is unknown, this is their estimated birth date. Otherwise, this is the date of the fetal loss. (A pregnancy that ends with the mother's death is considered as a spontaneous abortion (fetal loss) for this purpose.)

This column may not be NULL.

The BSTATUSES.Bstatus categorizing the quality of the birth date estimate.

This column may not be NULL.

Sex

The sex of the individual. The legal values are:

Valid Sex Values
Code Description
M the individual is male
F the individual is female
U the individual is of unknown sex

This column may not be NULL.

The maternal group of the individual, the Gid of the group into which the individual was born.

This column must contain a Gid value of a row on the GROUPS table. This column may not be NULL.

Tip

If the maternal group is not known, the maternal group should be recorded as the unknown group.

Matgrpconfidence (confidence in maternal group assignment)

The degree of confidence in the assignment of the Matgrp value. The legal values for this column are defined by the CONFIDENCES support table.

This column may not be NULL.

Statdate

The status date of the individual. When the individual is alive, this is the latest date on which the animal was censused and found in a group.

This column may not be NULL.

The state of the individual's life at the Statdate. The legal values for this column are defined by the STATUSES support table.

This column may not be NULL.

The cause of death or circumstances associated with death. The legal values for this column are defined by the DCAUSES support table.

This column may not be NULL.

Alt_Snames (Alternate Short Names Exists)

A boolean value indicating whether or not there exist rows on the ALTERNATE_SNAMES table related to the individual's Sname. This value is true if and only if there exists a row on ALTERNATE_SNAMES with an Sname value which is the individual's sname or there exists an ALTERNATE_SNAMES row with a Alternate_Sname value which is the individual's sname.

The value in this column is automatically maintained and will never be NULL.

Entrydate

The date the individual entered the study population.

Note

Because of Interpolation, it may seem like this column could be maintained automatically. However, the opacity of "non-interpolating" rows in CENSUS and the related historical analyses prevent accurate automatic determination of the entry date for many individuals. For more information, see CENSUS.Status and Interpolation, Data are not Re-Analyzed.

This column can be NULL, only if the row represents a fetal loss.

Entrytype

The way the individual entered the study population. The legal values for this column are defined by the ENTRYTYPES table.

This column can be NULL, only if the row represents a fetal loss.

DcauseNatureConfidence (Confidence in Nature of Death)

The degree of confidence in the nature of the individual's death or circumstances associated with the individual's death (their DCAUSES.Nature). The legal values for this column are defined by the CONFIDENCES support table.

This column may not be NULL.

DcauseAgentConfidence (Confidence in Agent of Death)

The degree of confidence in the agent of the individual's death or circumstances associated with the individual's death (their DCAUSES.Agent). The legal values for this column are defined by the CONFIDENCES support table.

This column may not be NULL.

EarliestBirth (Earliest estimated Birth date)

The earliest estimated birth date for this individual.

The values in this column may be calculated automatically, as discussed above.

This column may be NULL, but only when the accuracy of the birth estimate is unknown (when Bstatus is 9.0).

LatestBirth (Latest estimated Birth date)

The latest estimated birth date for this individual.

The values in this column may be calculated automatically, as discussed above.

This column may be NULL, but only when the accuracy of the birth estimate is unknown (when Bstatus is 9.0).

CENSUS (Group Membership)

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

Tip

One way to have Babase record that an individual is alone is to first create a row in GROUPS meaning alone, and then to assign individuals who are alone to this group. The alone-ness of an individual can then be tracked in the same fashion as group membership, although the Babase user does then need to be aware that the members of the alone group are not actually proximate to one another.

The system will report individuals who are first censused in a group other than their maternal group (BIOGRAPH.Matgrp). The exception to this is when the maternal group is the unknown group or censuses that record absence.

The system will report individuals with a 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.

The original field census data sheets can be recovered from CENSUS, with one exception. 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.[35] 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.

Caution

Be careful when changing these data. When CENSUS data are inserted, deleted, or updated, the MEMBERS table and BIOGRAPH.Statdate column are automatically updated via Interpolation. Also, remember that rank will almost certainly change should group membership change.

Cenid

A unique identifier. This is an automatically generated sequential number that uniquely identifies the row. Cenid links CENSUS to DEMOG.

This column may not be NULL.

Date

The date of the census, or the date of the demography note (when Status is D).

Note

The date value must not be more than a year later than the present moment. This rule prevents accidental data entry errors from creating so many rows in MEMBERS that all available disk space is used.

This column may not be NULL.

The individual whose location is being recorded. The three-letter code that uniquely identifies an individual in BIOGRAPH. There will always be a row in BIOGRAPH for the individual identified here.

This column may not be NULL.

Grp

The group where the individual is located. This is a Gid value from GROUPS. This column should contain the most specific sub-grouping available -- subject to the constraints of the data entry protocol, of course. Aggregation into larger groupings is accomplished by retrieving the associated MEMBERS.Supergroup of the individual on the date of census.

This column may not be NULL.

Note

Usage exception: For dates between 21 Mar 1990 and 29 Feb 1992, inclusive, the group recorded for the sub-groups of Alto's group do not necessarily reflect the actual groupings of the animals on a particular day, but are instead indications of the group-splitting process. See the Protocol for Data Management: Amboseli Baboon Project document for further explanation.

Status

A one letter code indicating the source of the location information. Status is the source of MEMBERS.Origin data. The current codes are as follows: C (census), A (absent), D (demography), and M or N (manual). Other values derived from analysis of historical data include: S, E, F, B, G, T, L, and R.

The CENSUS.Status Codes

C

(census) The animal was found in the group on a field census sheet: from the census datasheets. (There may or may not be a corresponding demography note on DEMOG as well.)

Tip

A C Status is marked on the field census data sheet as an X.

A

(absent) The animal was not found in the group on a field census sheet. Note that while an individual should not be recorded present in more than one group on the same day, s/he may be absent from several groups on any given day.

Tip

An A Status is marked on the field census data sheet as an 0.

D

(demography) The animal was noted, in the field notebooks or elsewhere, to be in a group but was not marked present in a field census of a study group on that day.[36] There should be a DEMOG row associated with the CENSUS row. The individual may or may not have been marked absent on the same group's field census for the day.[37]

Tip

A D Status is marked on the field census data sheet as an 0, when there exists a corresponding place on the census data sheet.

Warning

The system will allow CENSUS rows with a Status of D to be entered without there being a corresponding DEMOG row in existence.[38] However it is expected that these rows exist only long enough to allow entry of a related DEMOG row. The system will report CENSUS rows with a Status of D that have no related DEMOG row.

M

(manual, interpolated) This code provides a way to manually supplement what is in the CENSUS table when there is no other way to get the data in. Babase considers this code to be the same as the C code.

N

(manual, not interpolated) This code provides an alternative way to manually supplement what is in the CENSUS table when there is no other way to get the data in. This code does not interpolate, it is presumed to be the result of some analysis.

S

(Susan's data) The data comes from the old DISPERSE database where the record had both a Datein and a Dateout.

E

(ending date) The data comes from the old DISPERSE database where the record had a Datein but not a Dateout.

F

(final date) The data comes from the old DISPERSE database where there is a Dateout and the last recorded location is before the Statdate.

B

(birth date) The data comes from the old DISPERSE database where the record had a Dateout but not a Datein.

T

(total) The data comes from the old DISPERSE database where the record had neither a Datein nor a Dateout.

G

(gap) The data are a record of the animal in the unknown group when the animal appeared in the old DISPERSE database but where there was a gap between times of recorded location.

L

(lineage) The group is from the Matgrp on the old CYCTOT database, either because the animal did not appear in the DISPERSE database, or because the first location for the animal in the old DISPERSE database had a Datein and this Datein was after the birth date of the animal.

R

(result of Alto's breakup) The datum is S, E, F, B, G, T, or L datum that has had locations which were changed from 1.0 to the group in which the animal was censused on 15/4/92. This change left all R rows as part of a contiguous series of days during which the animals are located in the Alto's sub-group as censused on 15/4/92, and the time-adjacent locations were not 1.0.

This column may not be NULL.

Cen

Cen is whether or not the CENSUS row represents an entry on a field census data sheet. TRUE means the CENSUS row exists because of an entry on a census data sheet, FALSE means there was no census done and the CENSUS row exists to support a demography note, manual notation of absence, etc. Cen should only be TRUE when Status is C, A, or D.

This column may not be NULL.

CONSORTDATES (First Consortship Dates)

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.

Tip

Currently it only contains values for males; females may be added if desired.

Tip

All dates are exact, no BY dates are entered as we do for MATUREDATES and RANKDATES, so there is no Status column.

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.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information from BIOGRAPH or other places where the animal's three-letter code appears. This column may not be NULL.

Consorted

The date the individual had its first consortship. This column may not be NULL.

DEMOG (Demography Notes)

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.[39] 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.

Tip

Use the DEMOG_CENSUS view to upload datasets into this table. Use CENSUS_DEMOG view to maintain this table by hand.

Caution

The data integrity rules require that when a demography note is entered the CENSUS row be created before the related DEMOG row.

A unique identifier. This is an automatically generated sequential number that uniquely identifies the row. Cenid links CENSUS to DEMOG.

This column may not be NULL.

Reference

A code that identifies the written field notebook or other source where the demography note can be found.

The legal values for this column are defined by the DEMOG_REFERENCES support table, see below. This column may not be NULL.

Comment

The demography note text pertaining to the CENSUS row with the given Cenid.

This column may be NULL.[40]This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

DISPERSEDATES (Dispersal Dates)

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.

Tip

All dates are exact, no BY dates are entered as we do for MATUREDATES and RANKDATES, so there is no Status column.

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[41] 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.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information from BIOGRAPH or other places where the animal's three-letter code appears. This column may not be NULL.

Dispersed

The date the individual (male) left its maternal group. This column may not be NULL.

Dispconfidence (Dispersal date confidence)

The degree of confidence in the assignment of dispersal date or rationale behind the assignment of the dispersal date. The legal values for this column are defined by the CONFIDENCES support table.

This column may not be NULL.

GROUPS (Groups)

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[42](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.

Tip

This table serves primarily as a tool for the system for data validation. To see its contents in a more human-readable format, use the GROUPS_HISTORY view.

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.

Tip

The MEMBERS.Supergroup column may be used to determine the supergroup of an individual on any given date.

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. [43]

Caution

The system enforces the rules of the 3 previous paragraphs "on-commit". In a transaction ending with a ROLLBACK, any changes to this table will not be validated against these rules. This means it is possible for an invalid change to appear error-free if executed in a rolled-back transaction. Committed transactions (and commands executed outside of transactions) perform this check as expected.

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.

Warning

Some gaps in BEHAVE_GAPS may have a Gap_Start date that is equal to the group's Start or Permanent date, implying that the gap started because of the opening of observation of the group.[44] Gaps may also have a BEHAVE_GAPS.Gap_End date equal to the group's Last_Reg_Census or Cease_To_Exist date, implying that the gap ended because of the group's end.[45] If the Start, Permanent, Last_Reg_Census, or Cease_To_Exist column is updated, then these implications will no longer be true. The system makes no attempt to judge whether these implications really are true or just coincidence, so data managers must exercise this judgment. When changing any of these dates in GROUPS, be sure to check for rows in BEHAVE_GAPS with Gap_Start or Gap_End dates that also should be updated, and correct them as needed.

Special Values

Group 9.0, Unknown, has a special meaning. Individuals are placed in this group by Interpolation when their whereabouts are unknown. Also, a SWERB_DATA.Seen_grp value of 9.0 in rows with an Event value of O indicates an exceptional circumstance where Seen_grp is allowed to equal the related SWERB_BES.Focal_grp value. Another group code for unknown whereabouts should not be created.

The 10.0 group has the special meaning of lone animal. The SWERB_UPLOAD view uses this value as the SWERB_DATA.Seen_grp when a lone animal is sighted. Another group code for lone animals should not be created.

The 99.0 group has the special meaning of predator sighting. The SWERB_UPLOAD view uses this value as the SWERB_DATA.Seen_grp when a predator is sighted. Another group code for predator sightings should not be created.

Column Descriptions

Gid

A positive numeric value with six digits (4 decimal places) that identifies the group. Each Gid must be unique. This column may not be NULL.

Name

The spelled out name of the group. This column must be unique, and unique insensitive of case. This column may be NULL. This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.

From_group

The Gid of the group from which this group split off, if the group is a fission product. This column may be NULL.

To_group

The Gid of the group formed when the daughter of the group is the result of group fusion.

This column may be NULL to indicate there is no daughter group or the daughter groups are fission products.

Permanent

This column contains the date the group became a permanent, regular group, or contains NULL if it has not and is a temporary daughter group. For groups that were created as a result of fissions or fusions this column represents the end date of the fission/fusion period. For groups that were already intact when observation began this column represents the first day of observation on that group.

Note

Permanent affects whether or not an individual can be censused only in a daughter group and still be ranked in the parent supergroup. See RANKS and MEMBERS.Supergroup for further information.

Start

The date the group came into existence (or the earliest date it must have existed in the case of those groups existent before they were monitored.) The value of this column may be NULL to indicate the group exists but is not monitored.

If any parent group has the daughter group as its To_group then the start date is also the date the fusion started.[46]

Cease_To_Exist

The date on which the group is deemed to have permanently dissolved into fission products or merged into a fusion product. This column may be NULL for groups still under observation, groups that have not yet dissolved/merged, and groups whose dissolution/merge occurred while not under regular observation.

Last_Reg_Census (Last Regular Census)

The date of the last regular census done on the group for study groups that were dropped or ceased to exist because of fission/fusion. This column may be NULL if the group hasn't been dropped or was never a study group.

Three_letter_code

A 3 character, and exactly 3 character, code that uniquely identifies the group. The characters must all be upper case. This code is used by the Psion data collection devices and in SWERB observations taken using handheld GPS units and exists solely as a cross reference from those devices to the regular Babase group Gids. This column may be NULL if the group is never monitored using the Psion devices or SWERB GPS devices.

One_letter_code

A 1 character, and exactly 1 character, code that uniquely identifies the group within the time period of the groups existence. The character must all be upper case. This code is used to cross reference SWERB waypoint data to the regular Babase group Gids. This column may be NULL.

Study_Grp

The date the group first became an "official" study group[47] or NULL if the group was never a study group.

MATUREDATES (Sexual Maturity Dates)

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[48], 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.

Caution

Changing a female's first Tdate can automatically change the female's Matured date. See CYCPOINTS.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information from BIOGRAPH or other places where the animal's three-letter code appears. This column may not be NULL.

Matured

This is the date of menarche for females and the date of testicular enlargement for males, when either of these dates are known. Otherwise, this is the date by which the individual is considered to be sexually mature. See the Protocol for Data Management: Amboseli Baboon Project for more information regarding the dates used when the transition to maturity was not observed.[49] This column may not be NULL.

Mstatus (Sexual Maturity Status)

The status of the maturity date, that is, its precision, accuracy, quality, or other pertinent characteristics when it comes to the use of the value. The legal values for this column are defined by the MSTATUSES support table, see below. This column may not be NULL.

Tip

This column records whether the animal became mature ON a given (known) date, or BY a given (known) date. If a date is designated as an ON date[50] then we are saying that we know the animal attained that marker ON that date.[51] If a date is designated as a "BY" date the animal was adult or subadult BY that date but we do not know when the individual attained it. This scheme allows easy identification of which animals are infants or juveniles on any given day and which are not.

RANKDATES (Adult Rank Attainment Dates)

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.

Tip

RANKDATES currently contains only data for males but data for females may be added.

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.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information from BIOGRAPH or other places where the animal's three-letter code appears. This column may not be NULL.

Ranked

The date the individual first attained a rank among adults. The date must fall on the first of the month. This column may not be NULL.

Rstatus

The status of the rank date, that is, its precision, accuracy, quality, or other pertinent characteristics when it comes to the use of the value. The legal values for this column are defined by the MSTATUSES support table. This column may not be NULL.

Tip

The legal values for this column are O (for ON) and B (for BY), as with Mstatus in the MATUREDATES table above.



[25] As opposed to using a query to let the database do all the considering for you.

[26] This is a generated error instead of one that is immediately raised in order to ease the data entry process. Because births are recorded before CENSUS rows are entered so that new births do not raise errors when uploading census data, new births regularly have dates that follow the mother's Statdate. This could be avoided by entering births without a Pid and then updating the Pid once the CENSUS table has been updated but this was deemed overly burdensome.

[27] Recall that when an individual has no non-absent CENSUS rows, their Statdate is set to their Entrydate, which might be before the LatestBirth. It is therefore presumed that a Statdate being before a LatestBirth will only ever be a temporary occurrence that will go away after the individual's CENSUS data have been added.

[28] If this is ever so, an Entrytype indicating "Birth" is arguably not appropriate.

[29] This number was chosen based on data management minutiae related to the fact that a single census in a group can interpolate an individual present in the group for up to 14 days. If this value in the interpolation code ever changes, then the number of days that LatestBirth is allowed to be after Entrydate should be re-evaluated.

[30] Thanks to the annoying habit of certain months to not be exactly thirty days — not to mention "leap days" — it's possible that different users may have slightly different interpretations of how many days are contained in "X" years. To allow some flexibility when making these estimates, this rule is implemented as a warning and not an error.

[31] This column was added when PostgreSQL depreciated its hidden identifier column, Oid.

[32] This is unlikely as the database will not allow entry of a duplicate Sname.

[33] At the time of this writing the Psion palmtop data collection devices use the Sname XXX for its own special purposes. There may be other such reserved Sname values unknown to Babase.

[34] Or whatever you want to call it in the case of a fetal loss.

[35] This is termed a visit in the Protocol for Data Management: Amboseli Baboon Project, which should be consulted for further details.

[36] D usually occurs when a male is seen alone or in a non-census group.

[37] When the Status column is D, the value of the Cen column indicates whether or not the individual was marked absent on the field census for the day.

[38] Facilities exist to require such CENSUS rows and their associated DEMOG rows be entered in a single transaction, and the rule requiring CENSUS rows with a Status of D to have a related DEMOG rows could then be enforced.

[39] DEMOG nearly makes the M CENSUS Status code obsolete, were it not so hard to search on textual data. Indeed, it was created in response to difficulties with the M code.

[40] It may seem odd that the Comment column may be NULL given that this is the only column in the table containing baboon-related data. However the data entered into the database can be an abbreviated version of the actual demography note, abbreviated even into non-existence.

[41] The system checks the group in which the individual was last censused present rather than the individual's Matgrp in order to accommodate group splitting.

[42] Presently group 9.0. This value is hardcoded at present.

Individuals are generally put in the unknown group when interpolation does not know their group membership, but it is also possible for an individual to be explicitly placed in the unknown group.

[43] This implies that a GROUPS row's From_group and it's To_group cannot be equal.

[44] As opposed to it being merely a coincidence that the gap began the same date that the group did.

[45] Again, as opposed to it being coincidence that gap and group ended at the same time.

[46] Because there is not a separate column for fusion start date Babase can only track fusions when all groups involved start fusing on the same date. Babase cannot track fusions involving more than one group when 2 groups begin to fuse and others fuse later before the first 2 groups complete fusing.

[47] The precise definition of an "official" study group is left for data management to determine.

[48] In constrast to birth and death, which mercifully tend to be pretty definite.

[49] At the time of this writing, the date used in the case where the transition to sexual maturity was not observed is the date when the individual first came under observation and was already mature.

[50] The ON date MSTATUSES code is a special value. See MSTATUSES: Special Values.

[51] Note that this is not literally true, because testicular changes in males are not tracked on a daily basis - males are assigned a matured date on the first day of the month in which seen with fully round testes. Likewise, a female's first Tdate will sometimes have a few days of error around it, as might other transitions.


Page generated: 2021-09-17T11:16:28-04:00.