One row for every unstructured data collection event recorded during all-occurrences protocols. The ALLMISCS row containing data collected during a particular sample is related to the SAMPLES row representing the sample. Samples do not have a fixed number of related rows on ALLMISCS, any particular sample may have one, none, or many. Further information may be found on SAMPLES.
A variety of ad-libitum data may be collected during sample data collection. Some of these ad-libitum data can be placed in the INTERACT_DATA and POINT_DATA tables, in which case ALLMISCS is not involved. The data that does not conform to the design of INTERACT_DATA and POINT_DATA is kept in the ALLMISC table.
Consortships recorded as ad-libitum data during focal point sampling are not stored on INTERACT_DATA because INTERACT_DATA requires that consortships have a starting and an ending time and data collected during focal point sampling is without duration. Such consortship data are stored as an ALLMISCS row. Babase presumes that all consortships are recorded systematically during the day on paper and entered into Babase and so it is not necessary to attempt to place ad-libitum consortship data recorded during focal sampling into INTERACT_DATA. . Consortship data are collected during focal samples in order to note whether focal animals are engaged in consortships during a particular sample, and not to record the consortship per se.
Mounts involving the focal individual during all-occurrences sampling are recorded both in the palmtop and on the paper field ad-libitum records. Consequently, to avoid duplicates in INTERACT_DATA, Babase stores the mounts recorded in the palmtop in the ALLMISCS table, but not the INTERACT_DATA table. Mounts in the ALLMISCS table are therefore redundant and may be ignored.
Babase does the same thing with ejaculations recorded on the palmtops as it does with mounts: it records them in ALLMISCS rather than INTERACT_DATA. However, the protocol says nothing about ejaculations occurring during all-occurrences sampling. Anyone researching ejaculations will need to investigate this further.
For further information regarding the information collected see the Amboseli Baboon Research Project Monitoring Guide. For further information regarding which ad-libitum data winds up in ALLMISCS see the Protocol for Data Management: Amboseli Baboon Project. For further information on the structure of the ad-libitum text stored in ALLMISCS see the documentation on the Psion palmtop data collection program(s).
The combination of Sid and Time must be unique.
A unique integer which identifies the ALLMISCS row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The time the ad-libitum data were taken. This column stores the time using a data type having a precision of one second but the precision and accuracy of the data values are dependent upon the palmtop's timekeeping, the operator, and the protocol and is surely not one second. Consult the Amboseli Baboon Research Project Monitoring Guide.
The time may not be before
05:00 and may not be after
19:00.
The unstructured ad-libitum information collected.
At present the text in this column actually does have some structure[76] but appears in ALLMISCS because Babase contains no other place suitable for the storage of the data. The text begins with a one letter code followed by a comma. The allowed one letter codes and their meaning are:
C
Consortship. This is redundant information. Because consortships happen over time these consortships should always also be independently recorded and therefore independently entered into INTERACT_DATA and PARTS.
U
Unknown. This was once reserved for
meta-information -- the field data collection team's
comments on the process of data collection -- but
its meaning has since become confused with the
O code.
O
Other. Other information about the baboons or
their environment. Its meaning has become confused
with the U
code.
For further information see the Amboseli Baboon Research Project Monitoring Guide.
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.
One row for every MPIS row (multiparty interaction) involving a consortship. This table extends the MPIS table to include information about consortships.[77]
A unique integer which identifies the MPIS row -- the multiparty interaction.
Because the CONSORTS table extends the MPIS table, the two tables have a one-to-one relationship, this value also uniquely identifies the CONSORTS row.
The value of this column may not be changed.
The disputed female. A BIOGRAPH.Sname of a female.
This column may be NULL when the
consorted female is unrecorded.
Exactly one row for every point collected using the
adult female sampling protocol. SAMPLES
rows with a Stype of
F have related FPOINTS
rows. The FPOINTS rows have the same id, a Pntid, as POINT_DATA. The FPOINTS rows hold the data unique
to the adult female protocol sampling method; there is exactly
one FPOINTS row for every POINT_DATA row in
the sample, exactly one row for every point taken under the
protocol. The system reports an error for those POINTS rows collected using the adult female
sampling protocol (having a SAMPLES.Stype of
F) that do not have a
related Fpoints row.
Although every FPOINTS row should have a related row on POINT_DATA, not every POINT_DATA row has a related FPOINTS row. If a point is not an adult female point then the point simply has no row on FPOINTS.
Because every FPOINTS row must have a related POINT_DATA row, when entering a point the POINT_DATA row must be entered before the FPOINTS row.
A unique identifier. This is an automatically generated sequential number that uniquely identifies the row. Pntid links FPOINTS with POINT_DATA in a one-to-one manner.
This column may not be NULL.
The position of the infant with respect to the focal female. The legal values for this column are defined by the KIDCONTACTS support table.
This column may not be NULL.
The suckling activity of the infant. The legal values for this column are defined by the SUCKLES support table.
This column may not be NULL.
This table contains a row for every recorded interaction between animals, including all-occurrence data taken during focal point samples but excluding multiparty interactions (MPI_DATA). Each row records when the interaction occurred. Further information on the interaction is stored elsewhere, notably PARTS. Each interaction in INTERACT_DATA is represented as though it occurs between two ordered individuals designated “actor” and “actee” -- thus resulting in two rows in the PARTS table.
The INTERACT view should always be used in place of this table. (See Views for the rationale.) INTERACT is an extension of this table which may be useful. It is identical to INTERACT_DATA but is extended with alternate representations of dates and times.
The ACTOR_ACTEES view provides a way to view interactions as a single rows.[78]
The date of the interaction must not be before the participants' Entrydate, or after their Statdate (with some exceptions. See PARTS for details). Therefore the demographic data for any particular time interval must be entered into Babase before that time period's social interaction data.
A female may not participate in a mount, consortship, or ejaculation interaction before menarche (MATUREDATES.Matured). A male may not participate in a mount, consortship, or ejaculation interaction before 4 years of age.[79]
Many rules surrounding INTERACT_DATA's values are
closely tied to the project's data collection protocols.
There are two sorts of data collected on behavioral
interactions: all-occurrences data
and ad-libitum data. All occurrences
data are collected only during focal animal samples. They are
data on all the occurrences of a particular behavior or
interaction during a given time interval and/or involving a
participating focal individual.[80] All occurrences data will always have an
INTERACT_DATA.Sid that is not NULL. Ad-libitum data are data
that are collected opportunistically at the will of the
observer; we do not assume that ad lib data capture all the
occurrences of a given behavior. Ad-libitum data, which
generally are not collected as part of focal animal samples,
usually have a NULL Sid value (only those
collected during a focal animal sample have a
non-NULL Sid). Some sorts of interactions
are only collected during focal sampling and not as ad libitum
data outside of focal samples. Approach (ACTS.Class =
P), and request to groom (ACTS.Class =
R) are these
interactions; they are only collected during all-occurrences
sampling and must have a non-NULL Sid.
Although consortship and mount[81] data are collected as all-occurrences data
during focal point samples, these data are also collected,
simultaneously and in more detail, in ad libitum
notes. Consequently, they appear in Babase as ad libitum data
in INTERACT_DATA, not as all occurrences data, and
consortships (ACTS.Class = C),
mounts (ACTS.Class =
M), and ejaculation (ACTS.Class =
E) rows always have a
NULL Sid.
An individual's all-occurrences interactions can be distinguished from ad-libitum data by using the Sid column to reference SAMPLES to see if the individual is the focal of an all-occurrences sample. An example is presented in Appendix B.
INTERACT_DATA rows having a related SAMPLES row, having a
non-NULL Sid[82], will automatically have an Observer value equal to the value
in the related SAMPLES.Observer column -- the system
automatically synchronizes observer values between related
INTERACT_DATA and SAMPLES rows. Such
automatically assigned values cannot be changed. To change
the observer the SAMPLES.Observer column must be changed.
Care must be taken when breaking a relationship
between INTERACT_DATA and SAMPLES, when
setting INTERACT_DATA.Sid to
NULL. The automatically assigned
INTERACT_DATA.Observer value
may no longer be correct and so may require manual
adjustment.
An INTERACT_DATA row with a NULL
Sid and a
non-NULL Observer cannot be updated with a
non-NULL Sid unless the Observer value is also set to
NULL -- manually assigning an observer to
an ad-lib interaction precludes relating the interaction to a
focal point sampling period. Setting Observer to NULL
when changing Sid to a
non-NULL value causes the system to
automatically assign the correct value to Observer -- causes the system to
automatically synchronize observers.[83] Likewise, an INTERACT_DATA row with a
non-NULL Sid cannot be inserted unless the
Observer value is either
NULL or matches that of the related SAMPLES.Observer value
-- new focal sample interactions must be consistent with
respect to the observers recorded in the INTERACT_DATA and
SAMPLES tables. When an INTERACT_DATA row
with a non-NULL Sid and a NULL
Observer value is inserted
then the Observer value is
automatically updated with the related SAMPLES.Observer value
-- again, the observer associated with the interaction is
automatically brought into sync with the focal sample.
INTERACT_DATA encodes interaction time and duration by
storing the start and stop times of the interaction. The
columns Start and Stop are used for this purpose.
Consortships may have a NULL in either the
Start or the Stop time when the respective value is unknown,
otherwise the Start time must precede the Stop time.
Ad-libitum sample agonism and grooming interactions (ACTS.Class values of
A and
G respectively) must have a
NULL in both the Start and Stop columns.
All-occurrences agonism, grooming, approach (ACTS.Class =
P), and request to groom (ACTS.Class =
R) interactions must
have non-NULL Start times that equal Stop
times. Start always equals Stop for mounts (ACTS.Class =
M) and ejaculations (ACTS.Class =
E).
The columns of this table that contain times, Start and
Stop, are stored using a data type that has a precision of 1
second. The Amboseli
Baboon Research Project Monitoring Guide must be consulted regarding
the precision and accuracy of these data. It is expected that
ad-libitum datum is entered with a 1 minute
precision.[84] Consequently the seconds portion of the time
values must always be 0 when Sid is NULL.
All-occurrences interaction data (Sid is not
NULL) do contain seconds.[85]
The system will report a warning for interactions which occur between individuals who are not in the same group on the date of the interaction.
A positive integer that uniquely identifies the
interaction. This number is assigned by the system. This
column must not be NULL.
The origin of the data. When the interaction data
were collected during all-occurrences sampling this column
holds a SAMPLES.Sid identifying the all-occurrences
sample during which the data were collected, otherwise
this column is NULL.
A code indicating the kind of interaction. The ACTS support table defines the legal values for this column.
Although Act contains ACTS.Act values, it is often the broader ACTS.Class classification that is of interest.
This column may not be NULL.
The date on which the interaction took place. This
column may not be NULL.
For grooming data prior to 2006-07-01 and agonism
data prior to 1995-01-01 only the month and year of the
interaction are valid.[86]
For these data, all of these dates must fall on the first
day of each month for that year, unless the data comes
from point sampling (the Sid column is
NULL). The data collected during point
sampling has accurate dates.
The time the interaction began or, in the case of all-occurrences data, the time the interaction was recorded in the field.
The data type of this column has a 1 second precision. The precision and accuracy of the data itself is dependent upon the protocol and the operator and is almost surely not 1 second. Consult the Amboseli Baboon Research Project Monitoring Guide.
The time may not be before
05:00 and may not be after
bb_day_end;.
This column may be NULL.
The time the interaction stopped or, in the case of all-occurrences data, the time the interaction was recorded in the field.
The data type of this column has a 1 second precision. The precision and accuracy of the data itself is dependent upon the protocol and the operator and is almost surely not 1 second. Consult the Amboseli Baboon Research Project Monitoring Guide.
The time may not be before
05:00 and may not be after
20:00.
This column may be NULL.
One row for each collection of multiparty interactions.
Multiparty interactions are recorded as an ordered series of dyadic interactions. Each complete series has a single MPIS row in the database.
This is a separate data set from the dyadic interactions recorded in INTERACT_DATA and related tables. Interactions appearing there do not appear in the multiparty interaction data, or vice versa.
The date of the multiparty interaction must be between the Entrydate and Statdate, inclusive, of all the participants.
The two participants in the dyadic interactions must be different individuals, the two MPI_PARTS.Snames must be different.
The Context column must be NULL when
the Context_type value is N,
no context.
The Context_type column must be C
(Consortship) and the Context column must be
NULL when a related CONSORTS row exists. The system will generate a
warning when the Context_type column is
C and there is no
related CONSORTS row.
A unique integer which identifies the MPIS row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
Multiparty interactions may be categorized by the context in which they occur. This column identifies the context of the multiparty interaction.
The legal values of this column are defined by the
CONTEXT_TYPES support table. This
column may not be NULL.
Multiparty interactions are recorded as collections of individual dyadic interactions. This table contains one row for every dyadic interaction of a multiparty interaction collection. Each interaction is represented as though it occurs between two ordered individuals designated actor and actee -- these individuals are recorded in the MPI_PARTS table. The dyadic interactions within the collection are time-wise sequenced. Two rows may have the same sequence number (Seq), indicating that the two interactions occurred simultaneously.
The MPI_EVENTS view provides a convenient way to view multiparty interactions as single rows.
Babase records little in the way of causality among the various interactions collected together under the multiparty interaction collection umbrella. At the time of this writing the data protocols require that the initial interaction is a kind of agonism or a kind of help request, so that can be considered causal of the remaining interactions. However there is nothing, other than time-wise sequencing, linking particular requests for help with aid supplied. As a result it is impossible, in the general case, to associate help supplied with help requested. For example, an individual may request help twice, from two different individuals, and then receive help from an third individual. The columns recording the results of help requests (Helped and Active) must therefore be used with caution, as must any attempt to correlate the specifics of help given with help requested.
Multiparty interactions which occur simultaneously must have the same MPIAct values.
The system will generate a warning when more than two MPI_DATA rows, sharing a Mpiid, have the same Seq value -- when there are more than two dyadic interactions occurring simultaneously.
The first interaction of a multiparty interaction
(those with a Seq of
1) must be an agonism or a request for
help, the MPIAct value must be that of an MPIACTS row having a Kind value of
A or
R.
The first interaction of a multiparty interaction
collection is expected to be a single dyadic interaction
unless otherwise allowed by the MPIACTS
table -- the first interaction of a multiparty interaction
collection may only occur simultaneously with another
interaction, the two dyadic interactions both having a Seq of 1, when all of
these initial interactions have MPIAct values that relate the rows to
MPIACTS rows having TRUE
Multi_first values.
The Helped and Active columns are meaningful when the
MPI_DATA row records a request for help.[87] These columns must be NULL
when the MPI_DATA row does not record a request for help,
otherwise they must not be NULL. The
system will generate a warning when the Helped column indicates that no help was
given but there are subsequent interactions which record help
being given (where the MPIAct
values have H MPIACTS.Kind values) to
the individual who requested help. The system will generate a
warning when Active is
TRUE and there are no subsequent
AH interactions where the
help-requestee is the recipient of help in the same
multiparty interaction collection. The system will generate
a warning when Helped is true and
Active is FALSE
and there are no subsequent
PH interactions where the
help-requestee is the recipient of help in the same
multiparty interaction collection.
A unique integer which identifies the MPI_DATA row, and thereby the interaction the row records.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
A number identifying the multiparty interaction collection (MPIS) of which the MPI_DATA interaction is a member.
This column cannot be changed and must not be
NULL.
This column records the kind of interaction which took place. The legal values for this column are defined by the MPIACTS support table.
This column may not be NULL.
The first interaction of each multiparty
interaction collection has a Seq value of
1, the second a value of
2, etc. The system will report an
error if the Seq does not begin with 1 or is not
contiguous.
The Seq values need not be unique, per Mpiid. Duplicate sequence numbers are used to indicate simultaneous interactions, as would happen if, e.g., 2 individuals aggressed against 1.
This column may not be NULL.
This column indicates whether help was given, by the
individual from whom help was requested, in response to a
request for help. Helped must be FALSE
when help was requested from an unknown
individual.[88]This column contains meaningful information
only for those MPI_DATA rows which record requests for
help. (See above.)
This column is TRUE when help was
given and FALSE when no help was
forthcoming.
This column may be NULL.
This column indicates whether help given was active or passive. It contains meaningful information only for those MPI_DATA rows which record requests for help. (See above.)
This column is TRUE when the help
supplied was active and FALSE when
either the help supplied was passive or when no help was
supplied. This column is NULL when the
MPIAct value represents an action other than a request for
help.
When looking for help requests that received passive help always check the Helped value to be sure that help was actually received.
This column may be NULL.
This table contains records of participants in the interactions which make up a multiparty interaction collection (MPIS). Each interaction is represented as though it occurs between two individuals designated actor and actee. Interactions between multiple individuals are broken down into interactions between pairs according to rules described in the protocols. Therefore, this table should contain two rows for every record of an interaction (for every row in MPI_DATA), one row to record the actor, and one to record the actee. Rules for classifying individuals as actor or actee are documented below in the description of the Role column.
The MPI_EVENTS view provides a convenient way to view multiparty interactions as single rows.
Every MPI_DATA row should be related to exactly two MPI_PARTS rows, otherwise it is an error. However, the system allows this condition to exist. It is presumed that such an error condition will exist for only as long as it takes to enter a complete set of data. The system will report those cases where there are not exactly two MPI_PARTS rows for every MPI_DATA row.
The data integrity rules require that the MPI_DATA row be entered before the 2 MPI_PARTS rows.
Either the Sname or the
Unksname column must be
NULL, but not both.
The actor and the actee of an interaction, when specified as Snames, must not be the same individual.
A unique integer which identifies the MPI_PARTS row, and thereby the participant in the interaction the row records.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
Multiparty interaction identifier. This column
holds the Mpiid value of the
row on the MPI_DATA table containing
further information on the interaction in which the animal
is a participant. It can be used to retrieve the other
information recorded on the multiparty interaction. There
must be a row in MPI_DATA with an Mpiid of this value. This column
cannot be changed and may not be
NULL.
A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information, such as the maternal group of the animal, from BIOGRAPH or other places where the animal's three-letter code appears.
This column must not be NULL when
the participating individual is precisely identified and
NULL otherwise.
The nature of the problem when one of the participants in the interaction cannot be precisely identified. The legal values of this column are defined by the PARTUNKS support table.
This column must be NULL when the
participating individual is precisely identified and not
NULL otherwise.
This column designates whether the row records the actor or the actee of the interaction. The two possible values are:
| Code | Mnemonic | Definition |
|---|---|---|
R
|
Actor | The actor is usually the one performing the act. For the agonism data, the individual that is the winner (does not perform a submissive behavior) is the actor. For help requests, the individual that is requesting the help is the actor. For help supplied, the individual supplying the help is the actor. For grooming data, the individual that is grooming is the actor. And so forth. |
E
|
Actee | The actee is usually the one that is the recipient of another animal's attentions. For the agonism data, the individual that is the loser (performing a submissive behavior) is the actee. For help requests, the individual of whom help is requested is the actor. For help supplied, the individual to whom the help is supplied is the actor. For grooming data, the individual that is groomed is the actee. And so forth. |
This column may not be NULL.
This table contains records of the participants in observed interactions between animals. Each row in the table records a participant. Each interaction is represented as though it occurs between two individuals designated actor and actee. Interactions between multiple individuals are broken down into interactions between pairs according to rules described in the protocols. Therefore, this table should contain two rows for every record of an interaction (for every row in INTERACT_DATA), one row to record the actor, and one to record the actee. Rules for classifying individuals as actor or actee are documented below in the description of the Role column.
Every INTERACT_DATA row must be
related to exactly 2 PARTS rows, excepting
those INTERACT_DATA rows that are
associated with ad-lib focal point sampling -- those that
have non-NULL
Sid values. Ad-lib
interactions collected during focal point sampling are
allowed to have only one participant, but only when that
participant is the focal individual. So that data can be
entered the system allows these error conditions to exist
while a transaction is in progress. These conditions are
validated on transaction commit.
The data integrity rules require that the INTERACT_DATA row be entered before the 2 PARTS rows.
The utility in the PARTS table, as opposed to having single rows for interactions as the ACTOR_ACTEES view does, is in writing database queries that search for interaction participants. It is easy to use PARTS to search for a participant without knowing whether the participant is the actor or the actee. The same is not true of the ACTOR_ACTEES view.
It is easy to produce the ACTOR_ACTEES view from INTERACT and PARTS, but the reverse would not be true. This is why the underlying database representation is as it is and not the reverse.
The date of the interaction must be between the Entrydate and Statdate, inclusive, of the participants. The exception are grooming interactions before January 1, 2006 and agonism interactions before January 1, 1995, as these are always given a first-of-the-month date. Consequently, the date of these interactions may be before the entrydate but the month and year of the interaction date may not be before the month and year of the birthdate and entrydate.
The actor and the actee of an interaction must not be the same individual.
A unique integer which identifies the PARTS row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
A three-letter code (an id) that uniquely identifies
a particular animal (an Sname) in BIOGRAPH. This code can be used
to retrieve information, such as the maternal group of the
animal, from BIOGRAPH or
other places where the animal's three-letter code
appears. This column may not be
NULL.
This column designates whether the row records the actor or the actee of the interaction. The two possible values are:
| Code | Mnemonic | Definition |
|---|---|---|
R
|
Actor | The actor is usually the one performing the act. For grooming data, the individual that is grooming is the actor. For the agonism data, the individual that is the winner (does not perform a submissive behavior) is the actor. For mounts, consortships, and ejaculations, the male is the actor. |
E
|
Actee | The actee is usually the one that is the recipient of another animal's attentions. For grooming data, the individual that is groomed is the actee. For the agonism data, the individual that is the loser (performing a submissive behavior) is the actee. For mounts, consortships, and ejaculations, the female is recorded as actee. |
This column may not be NULL.
Interaction identifier. This column holds the Iid value of the row on the
INTERACT_DATA table containing further
information on the interaction in which the animal is a
participant. It can be used to retrieve the other
information recorded on the interaction. There must be a
row in INTERACT_DATA
with an Iid of this value. This column may not be
NULL.
One row for every point observation collected on a focal individual during a sampling interval. When, for whatever reason, there are no point data collected on the focal individual at the turn of the minute, there is no row on POINT_DATA. The “position” of the points within the sample, Min value, may therefore contain “gaps” -- missing numbers. The “missing numbers” are points taken when the focal animal is out of sight or the point was missed for whatever reason. Babase represents the observational period during which a sample is collected as a SAMPLES row.
Always use the POINTS view in place of this table (see Views for the rationale.) It contains additional computed columns which may be of interest and is guaranteed to remain consistent in future Babase releases.
A POINT_DATA row must contain a Foodcode when the Activity column indicates the focal is
feeding, otherwise Foodcode must be
NULL.
Consistency is enforced with respect to time taken to collect the sample and the number of point observations. The Min value must not be larger than the Mins of the corresponding sample.
A unique identifier. This is an automatically generated sequential number that uniquely identifies the row and is used in other tables to refer to particular points.
The sample (SAMPLES row) of which the point is a member.
The ordinal number of the point within the sample.
The first point in the sample has a Point value of
1, the second a Point value of
2, etc. Note that these numbers need
not be contiguous since some points are
“lost” during data collection. (See above.)
This column cannot be NULL.
The time the point was recorded. This column stores the time using a data type having a precision of one second. The precision and accuracy of the data values are dependent upon the palmtop's timekeeping, the operator, and the protocol and is surely not one second. Consult the Amboseli Baboon Research Project Monitoring Guide.[89]
It is unlikely that the researcher is interested in this data because, as of January 2006, the field protocols require no particular relationship between the time of the point and the time the observer records the data.
The time may not be before
05:00 and may not be after
19:00.
This column may not be NULL.
An Activity code from the ACTIVITIES table describing the activity of the individual when the point was taken. Note that some activities are restricted based on the sampling protocol. (Whether the Juvenile/Infant or Adult Female protocol is used to collect the data. See ACTIVITIES and SAMPLES.Stype.)
This column may not be NULL.
A Posture code from the POSTURES table describing the posture of the individual when the point was taken. Note that some postures are restricted based on the sampling protocol. (Whether the Juvenile/Infant or Adult Female protocol is used to collect the data. See POSTURES and SAMPLES.Stype.)
This column may not be NULL.
Food item eaten when the point was taken, if any.
NULL when no food items are eaten. The
legal values for this column are determined by the FOODCODES support table.
The neighbors of the focal individual are recorded during point sampling. NEIGHBORS contains one row for every neighbor recorded during a point data collection event (minute). The protocol used to record neighbors of the focal individual has changed over time.[90] See the Amboseli Baboon Research Project Monitoring Guide for further information.
A focal individual's neighbors are not always
recognizable or for some other reason do not always have a row
in BIOGRAPH. For this reason NEIGHBORS
contains two different columns used to identify the neighbor,
Sname and Unksname. The first for recording known
neighboring individuals and the second for recording unknown
neighboring individuals. One and only one of these columns
must contain a value, the other column must then contain
NULL.[91]
The system will report a warning when the neighbor is not in the same group as the focal individual.
The neighbor must be alive and in the study population on the day of the sample (SAMPLES.Date, as discovered via POINT_DATA.Sid) -- the day of the sample may not be before the neighbor's Entrydate and may not be after the neighbor's Statdate.[92] This means that the demographic information for a particular time interval must be entered into Babase before the sample data for that interval.
Each point observation (Pntid value) may have at most one NEIGHBORS row of a given neighbor classification (Ncode value.) The combination of Pntid and Ncode must be unique.
The NCODES table places restrictions on which individuals can be neighbors. One effect of this is to limit the order in which NEIGHBORS may be added to and deleted from Babase.
The sample's focal individual (SAMPLES.Sname, as discovered via POINT_DATA.Sid) may not be her own neighbor.
The combination of Pntid and Sname must be unique.
A unique integer which identifies the NEIGHBORS row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
A number that uniquely identifies the point for which the neighbor was recorded. Pntid links NEIGHBORS with POINT_DATA. Further information related to the entire sample must be found by using POINT_DATA.Sid, the sample identifier.
This column may not be NULL.
The neighbor of the focal individual. 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 must be NULL when the
neighbor is an unknown individual or otherwise not in
BIOGRAPH.
Different protocols classify neighbors differently. This column describes the kind of neighbor the row represents.
The legal values of this column are defined by the NCODES support table, which also determines which Ncodes may be used with which point sampling protocols (with which SAMPLES.Stype).
This column may not be NULL.
One row for every continuous period of time during which data are collected at regular intervals on a specific focal individual. Although the field protocols center around collecting data primarily stored in the POINT_DATA table, other information, normally collected during ad-libitum data collection, may be collected as well and are also associated with the sample set. Further, a sample is allowed to contain no (animal) information.[94]Each SAMPLES row contains the information pertaining to all the data collected during the sample.
The date of the sample must not be before the focal individual's Entrydate, nor after the focal individual's Statdate. Therefore the demographic data pertaining to any particular time period must be entered into Babase before the sample data collected during that time period.
The number of point observations occurring during the sampling interval (Minsis) must be less than or equal to the total number of minutes elapsed (Mins) during the sampling interval.[95]
Although the goal is to sample females as juveniles only prior to menarche and exclusively as adults following menarche, there is a margin for error. For example, a female may have a false start toward menarche where she begins to swell and is sampled as an adult but then the swelling turns out to be extremely small and, in hind sight, is not considered to be the onset of menarche. On the other hand, females may continue to be sampled as juveniles for a short period of time after onset of menarche. Since the two sample types contain different data, the data collected cannot be easily changed from juvenile to adult or vice versa. Therefore, in order to prevent loss of data for females near menarche, juvenile data is allowed for a short time following a female's maturedate or a male's rankdate and adult data is allowed for a short time prior to a female's maturedate.
Females may have juvenile
(Stype=J) SAMPLES rows
until their first conception. Males (or those of unknown sex)
may have juvenile (Stype=F)
SAMPLES rows for up to but not including 1 year after ranking
(RANKDATES.Ranked).
Only females may have female samples
(Stype=F). Females may not
have female samples more than 1 year before maturity (MATUREDATES.Matured).
The system will report a warning when the group (Grp) of the focal individual, as recorded on SAMPLES, is not the same as the group MEMBERS records for the focal individual on the date of data collection.
One of the participants in all interactions collected during the sample (see INTERACT_DATA.Sid and PARTS) must be the focal individual.
The Psion palmtops collect data using a custom program. That program in turn is driven by what is called a setup file, which controls the data collection procedure. The data collection procedures can thereby be changed without having to enlist the services of a programmer. However, it is likely that changes in the kind of data collected will require enhancements to Babase as the database structure is closely tied to the nature of the data. The sandbox schema may be used to extend Babase in an informal or temporary basis to work around this problem.
Some of the information in this table is related to the mechanics of data collection and the Psion palmtops and not particularly relevant to research, or perhaps much of anything, but is recorded here anyway should the information ever be found useful.
A unique identifier. This is an automatically generated sequential number that uniquely identifies the row and is used in other tables to refer to a particular sample.
The date of the sample set.[96] This column may not be
NULL.
The time the sampling began. The data type of this
column supports a 1 second precision, however as of Jan
2007 the Psion palmtop data has a 1 minute precision.
This column might be used to compute the actual times of
the related point observation. This column can not be
NULL.[97]
This column may be NULL for
pre-2007 data because the program that loads the Psion
palmtop data into Babase did not retain this
information.[98]
The group of the focal individual. The legal values for this column are from the Gid column of the GROUPS table.
This column may not be NULL.
A three-letter code (an id) that uniquely identifies
the focal 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.
A code indicating the nature of the focal individual and the data collection procedure used. The legal values are:
| Code | Mnemonic | Description |
|---|---|---|
J
|
Juvenile | Juvenile/infant focal sampling procedure |
F
|
Female | Adult female focal sampling procedure |
This column may not be NULL.
The total number of minutes which actually elapsed while the sample was collected, as determined by the number of point observations reported by the palmtop.[99] Although the protocols designate how many minutes should elapse, samples collected in the field do not always conform to the protocol for various reasons. For further information see the Amboseli Baboon Research Project Monitoring Guide.
This value must be zero or larger and less than or equal to 10.
This column may not be
NULL.
The actual number of point observations taken during the sample. Although the protocols (currently) specify that observation is to occur on 1 minute intervals during sampling, for various reasons sometimes observations are “missed”.
Babase maintains this value automatically by counting the number of POINT_DATA rows associated with the sample. If this value is manually set Babase compares the supplied value with the value it computes and issues an error if the two do not match.
This value must be zero or larger.
This column may not be
NULL.
Initials of the person who collected the sample. The legal values of this column are defined by the OBSERVERS support table.
This column may not be NULL.
The palmtop computer used to collect the sample. The legal values for this column are defined by the PALMTOPS support table.
This column may not be NULL.
The unique identifier of the program, including program version, used on the palmtop to collect the data in the sample. The legal values for this column are defined by the PROGRAMIDS table.
This column may be NULL as older
versions of the software that runs on the Psion palmtop
did not record this information.
The version of the Psion palmtop setup file or corresponding version identifier of whatever is used on the palmtops to collect the data in the sample. The legal values for this column are defined by the SETUPIDS table.
This column may be NULL as older
versions of the software that runs on the Psion palmtop
did not record this information.
[76] notably consortships
[77] There is no restriction on the age or maturity status of the female.
[78] This is not always as useful as it seems. See the rationale for the PARTS table.
[79] It is not that these interactions never occur among young individuals, it is that the researchers' interest is in paternity and maternity and so find that having to concern themselves with filtering out sexual interactions between juvenile individuals is distracting.
[81] and perhaps ejaculation
[82] Presumably data that is collected on a Psion.
[83] Requiring INTERACT_DATA.Observer be
NULL, even when the existing value is
“correct” and synchronized with SAMPLES.Observer,
ensures that the value of the observer column has been
taken into consideration by the person modifying the
database.
[84] Consult the Amboseli Baboon Research Project Monitoring Guide to be sure, but this is because the accuracy of the data are never more than one minute, if that.
[85] See the appendix: The All-Occurrences Focal Point Data.
[86] At the time of this writing the first half of the 2006 grooming data were given first-of-the-month dates, although the database does not require this. This may be fixed by the time you read this.
[87] Whether or not a MPI_DATA row records a request for
help is determined by whether or not the value of the
related MPIACTS.Kind column is
R.
[88] Because the individual from whom help was requested is unknown, there is no way to tell if help was given in response to the request.
[89] Note that if we had the time the sample started, to the second, and we knew that the operator never took more than 59 seconds to enter the point data, and we assume that the operator makes the observation when the timer chimes, then we could calculate the actual time the point was observed. Absent these conditions there appears difficult or impossible to tell which of the 1 minute observation intervals were missed when there is not an exact match between the number of points taken and the total number of minutes in the sample.
[90] However, at the time of this writing, Babase did not contain any data collected before the protocol changed.
[91] It is possible to create a view that extends the
NEIGHBORS table by adding another column, call it
Neighbor, that contains either the Sname or the Unksname,
which ever is not NULL. However, the
utility of such a column is not obvious because it seems
that any analysis done using such a column would have to
consistently use outer joins and then constantly test for
NULL results, lest the Unksname data
disappear from the analysis. At first glance this seems
similar to the testing which must be done to when using
two separate columns, the existing design, so it is not
clear whether there's anything to be gained.
Such a view can always be added in the future without breaking backward compatibility.
[93] The information on the actual unknown neighbor codes used in the field does not appear to be in the Amboseli Baboon Research Project Monitoring Guide.
[94] The name of the focal individual is always recorded, as there is always the intention to observe the focal individual even though this does not always happen.
[95] As the values in the POINT_DATA.Ptime column has little to do with the actual time of observation, it is impossible for Babase to perform additional consistency checks to between the points and the corresponding summary information in SAMPLES. Fortunately, as the data loading process is automated, there is little opportunity for data corruption.
[96] As all observation occurs during the day there are no issues surrounding samples taken just before midnight that start on one day and end on the next. Should there ever be such, this should be the date the sample started.
[97] The POINTS table contains only the time the data were entered into the palmtop. This could be a considerable time after the observation. Assuming the observations are taken as prescribed at regular intervals after the start of sampling the actual observation times might be derived by adding 1 minute increments to the time sampling started, and then adjusting for missed intervals using the time of data entry as a guide.
Unfortunately the low precision of the Psion palmtop data makes this an unrewarding exercise. Further, the sample starting time supplied by the palmtop may not be the actual time the sample was started. There may be some delay before the sample begins. See the Amboseli Baboon Research Project Monitoring Guide.
[98] Should Babase ever be updated with the old data, this column should be merged with the Date column to facilitate comparisons that involve both date and time.
[99] The Psion palmtop computers deliver data for every minute of the sampling set interval. Those minutes during which, for whatever reason, no data were collected have no corresponding row in POINT_DATA. But the program which loads the Psion palmtop's data into Babase (see Psionload) notes the existence of these minutes in the Mins value it constructs.