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.
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.
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.
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.
This table indicates periods of time during which behavioral data (e.g. interactions, focal sampling) may be sparse or lacking for an indicated group. Data from indicated 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. This table points out such periods and allows users to decide for themselves how to deal with them.
The reason for each gap is also noted. Reasons for gaps vary widely, so these reasons 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.
A unique integer identifying the BEHAVE_GAPS row.
This column is automatically maintained by the
database and must not be NULL.
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.
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.
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.
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.
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 the cause of
death, must have a Dcauseconfidence
of 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).
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 such 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.
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.
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.
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.
A unique integer identifying the BIOGRAPH row.
Babase does not use this identifier, it exists for the convenience of application programs. This column provides a convenient way to distinguish individuals without Snames, fetal losses, from each other and from other individuals.[27]
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
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.
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. [28] 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.[29]
This column should only be NULL if the
row represents a fetal loss.
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.
The Pid value, from the PREGS
table, of the individual's mother's pregnancy that ended
in the birth[30]of the individual. This column may be
NULL. A NULL value
indicates there is no record of the individual's
mother.
This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.
The date the pregnancy ends. If the pregnancy results in a live birth, this date is the birth date of the offspring, 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.
Birthday status. This column records the quality of the birth date estimate. The legal values for this column are defined by the BSTATUSES support table.
This column may not be NULL.
The sex of the individual. The legal values are:
| 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 sub-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.
If the maternal group is not known, the maternal group should be recorded as the unknown group.
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.
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.
The degree of confidence in the cause of death or circumstances associated with death. The legal values for this column are defined by the CONFIDENCES support table.
This column may not be NULL.
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.
The date the individual entered the study population.
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.
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.
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.)
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 system will report a warning when CENSUS rows have a Status
of C and a Date 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.[31] 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.
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.
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.
The date of the census, or the date of the
demography note (when Status is
D).
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.
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 Supergroup from GROUPS and/or use of the supergroup() function.
This column may not be NULL.
Usage exception: For the years 1989-1991, 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 Protocol for Data Management: Amboseli Baboon Project document for a further explanation.
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.)
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.
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.[32] 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.[33]
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.
The system will allow CENSUS rows with a
Status of D to be
entered without there being a corresponding DEMOG row in existence.[34]
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 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.
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.
Currently it only contains values for males; females may be added if desired.
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.
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.[35] 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.
Use the DEMOG_CENSUS view to upload datasets into this table. Use CENSUS_DEMOG view to maintain this table by hand.
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.
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.
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.
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[37]
and the Dispersed date is not after the earliest such
post-Statdate census date.
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.
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.
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
sub-groups and the special group “Unknown”[38](See the Protocol for Data
Management: Amboseli Baboon Project for when to use this
special group.) When a sub-group becomes a regular group
(after a fission 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” sub-groups that did not become permanent
should be left in GROUPS to support the sub-grouping membership
history.
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 and must not have their
own Gid value as their Supergroup. Permanent
groups must not have a Permanent
value that is earlier than their Start value, and must have their own Gid as their Supergroup. Permanent
groups may or may not have a NULL From_group value. During data entry for
groups that are fission products of other groups, the fission
products have the parent group as their Supergroup. This is a
temporary condition for those fission groups that go on to
become groups of their own.
Note that there is no particular reason to remove from GROUPS those sub-groups that exist for only a short time during group fission. Those sorts of groups can remain temporary forever.
A GROUPS row's From_group value may not be the same as its Gid value.
The supergroup() function can be used to determine the supergroup of a group on any given date.
A group's Permanent and From_group cannot both be
NULL. But both can be
non-NULL.
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.
The Cease_To_Exist value must
be NULL or greater than the Start value. The Cease_To_Exist value must also be greater
than or equal to all subgroups' Start
values.
The Cease_To_Exist must equal
the Permanent date of any subgroups,
unless the subgroup's Permanent is
NULL.
The system enforces this rule "on-commit". In a
transaction ending with a ROLLBACK, any
changes to this table will not be validated against this
rule. 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.
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.[39] 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.[40] 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.
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 (Gid 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.
A positive numeric value with five digits (3 decimal
places) that identifies the group. Each Gid must be
unique. This column may not be
NULL.
The spelled out name of the group. This column must
be unique, and unique insensitive of case. This column
may not be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
The Gid of the
group from which this group split off, if the group is a
fission product (or the larger of the two groups that
fused to form it, if the group is a fusion
product).[41]
This column may be NULL.
This column contains the date the group became a
permanent, regular group, or contains
NULL if it has not and is a temporary
sub-group. For groups that were created as a result of
fissions or fusions (and therefore have a
non-NULL From_group), this
column represents the end date of the fission/fusion
period. For groups that were already intact when
observation began (and therefore have a
NULL From_group), this
column represents the first day of observation on that
group.
Permanent affects whether or not an individual can be censused only in a sub-group and still be ranked in the parent supergroup. See RANKS and supergroup() for further information.
The Gid of the
permanent group to which this group belongs. Most of the
time this will be the same as the Gid column, but if the group
is a temporary subgroup (Permanent is
NULL) then this will be the first
permanent group from which this group has descended. This
column is maintained automatically by the system and
should not be entered manually.[42]
This column may not be NULL.
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.
The date on which the group is deemed to have
permanently dissolved. This column may be
NULL for groups still under
observation, groups that have not yet dissolved, and
groups whose dissolution occurred while not under regular
observation.
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.
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.
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.
A boolean that indicates whether or not this group
has ever been an "official" study group.[43]
This column may not be NULL.
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[44], 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
2798 days of age. This is about 7.5 years of
age. 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.
Changing a female's first Tdate can automatically change the female's Matured date. See CYCPOINTS.
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.
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.[45] This column may not be
NULL.
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.
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[46] then we are saying that we know the animal attained that marker ON that date.[47] 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.
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.
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.
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.
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.
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.
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] This column was added when PostgreSQL depreciated its “hidden” identifier column, Oid.
[28] This is unlikely as the database will not allow entry of a duplicate Sname.
[29] 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.
[30] Or whatever you want to call it in the case of a fetal loss.
[31] This is termed a visit in the Protocol for Data Management: Amboseli Baboon Project, which should be consulted for further details.
[32] D usually
occurs when a male is seen alone or in a
non-census group.
[33] 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.
[34] 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.
[35] 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.
[36] 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.
[37] 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.
[38] 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.
[39] As opposed to it being merely a coincidence that the gap began the same date that the group did.
[40] Again, as opposed to it being coincidence that gap and group ended at the same time.
[41] This selection of the larger From_group after a fusion should be made by the user. The system itself does not care about the size of the parent group(s), or whether a group started because of a fission or fusion.
[42] Technically, because this column is computed it need not exist. Still, it is convenient to have this column be pre-computed by the system at the time data are entered, rather than have this column be part of a view or computed dynamically when other data are validated.
[43] The precise definition of an "official" study group is left for data management to determine.
[44] In constrast to birth and death, which mercifully tend to be pretty definite.
[45] 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.
[46] The “ON” date MSTATUSES code is a special value. See MSTATUSES: Special Values.
[47] 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.