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 focal sample data and on the paper field ad-libitum records. Consequently, to avoid duplicates in INTERACT_DATA, Babase stores the mounts recorded in the focal data 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 in the focal data 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 that is eventually stored in ALLMISCS, see the documentation for the focal sampling data collection program, or see the Amboseli Baboon Research Project Monitoring Guide if the focal sampling data were handwritten.
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 focal data collection system'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[85] 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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
One row for every MPIS row (multiparty interaction) involving a consortship. This table extends the MPIS table to include information about consortships.[86]
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.
The male who consorted with the female prior to the multiparty interaction. A BIOGRAPH.Sname of a male.
This column may not be NULL.
The male who consorted with the female after the multiparty interaction. A BIOGRAPH.Sname of a male.
This column may not be NULL.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
This table contains data from focal sampling points during which the observer recorded information about the focal individual's infant, one row for each focal sampling point. Any focal sampling protocol that includes recording this kind of information is almost certainly going to require that the focal individual be a female, hence the "F" in this table's name.
Despite its name, this table does not require that a focal individual be of any particular Sex. Requirements like those are set and enforced by the STYPES.Sex column.
Whether or not a focal sample is allowed to have data in this table is determined by the sample's SAMPLES.SType and that SType's related STYPES.Has_FPoints value. See the STYPES table for more information.
Each FPOINTS row is connected to a POINT_DATA row via the Pntid column. That is, each row in this
table must have exactly one row in POINT_DATA with the same Pntid. The system will report a
warning for those POINT_DATA rows that
belong to a sample whose SType's related Has_FPoints is TRUE but which do not have
a related FPOINTS row. While every FPOINTS row must have a
related row in POINT_DATA, not every POINT_DATA row has a related FPOINTS row.
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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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.[87]
The actual Date of an
interaction is usually known. However, in some cases only the
year and month of an interaction were recorded without specifying
the day. The specificity (or lack thereof) of the Date is indicated by the boolean
Exact_Date column. When Exact_Date is FALSE, this
indicates that the year and month of the Date are known, but not the day. In
these cases, the Date must be
the first day of the month.
The Date of the interaction is constrained by various related dates of its participants, as follows:
The Date cannot be
before a participant's Entrydate, with one exception. When
Exact_Date is FALSE the
Date can be before the
participant's Entrydate, but
the month and year of the Date cannot be before those of
the participant's Entrydate.
A female may not participate in a mount,
consortship, or ejaculation interaction before menarche
(MATUREDATES.Matured). When Exact_Date is FALSE the Date may be before her Matured date, but the month and
year of the Date cannot be
before those of her Matured
date.
A male may not participate in a mount, consortship,
or ejaculation interaction before 4 years of
age[88]. When Exact_Date is FALSE the Date may be before he reaches
that age, but the month and year of the Date cannot be before the month
and year in which he reaches that age.
The system will return a warning when the Date is before the LatestBirth of either participant in
the interaction. When Exact_Date is FALSE, the Date may be before the
LatestBirth but the month and year of the Date cannot be before the month
and year of the LatestBirth.
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.[89] 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[90] 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[91], 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.[92] 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.[93] 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.[94]
When more than one observer is with a group at the same time, they are responsible for making sure that each interaction is only recorded in only one notebook, not duplicated across multiple observers' notebooks (see the Amboseli Baboon Research Project Monitoring Guide for more details). For this reason, it should be emphasized that the Observer column only indicates who recorded this row's interaction (when known), not who actually saw it.
An interaction's Handwritten must be FALSE when
Sid is not NULL.
It is physically possible for interactions associated with a focal sample to be handwritten, but in practice this never occurs. Interactions associated with focal samples are always recorded electronically.
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 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
20:00.
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.
A boolean indicating whether or not the observer
recorded the interaction by hand[95]
. This value is TRUE if yes, FALSE if no.
This column may not be NULL.
A boolean indicating whether or not the Date is the specific date of the interaction.
This column defaults to TRUE, and cannot be
NULL.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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 system will return a warning for each participant whose LatestBirth is after the date of the interaction.
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.
Unstructured text describing the context in which the multiparty interaction occurred.
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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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.[96] 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.[97]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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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_DATA 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 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.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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.
Validation of the Activity and Posture columns partially depends on the row's related SAMPLES.SType. The STYPES_ACTIVITIES and STYPES_POSTURES tables define which SType values can be used with which Activity and Posture values, respectively.
Changing the Sid risks data integrity issues that are not easily prevented with simple data checks, especially with the calculating of Minsis. Because of this, the Sid can only be changed by an administrator or superuser.
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.
This column may not be NULL.
The SAMPLES.Sid of the focal sample during which this point was collected.
This column may not be NULL.
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 may not 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 focal data collection system's timekeeping, the operator, and the protocol and is surely not one second. Consult the Amboseli Baboon Research Project Monitoring Guide.[98]
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.
The ACTIVITIES.Activity of the individual when the point was taken.
Some values from ACTIVITIES may be restricted, based on the sampling protocol. See STYPES_ACTIVITIES for more information.
This column may not be NULL.
The POSTURES.Posture of the individual when the point was taken.
Some values from POSTURES may be restricted, based on the sampling protocol. See STYPES_POSTURES for more information.
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 timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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).
When no neighbor is observed for a particular neighbor type (Ncode), no new rows are added to this table. This is different from how an "unknown" neighbor is recorded, as discussed below.
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.[99]
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.[100] This means that the demographic information for a particular time interval must be entered into Babase before the sample data for that interval.
The system will report a warning when the related Date is before a neighbor's LatestBirth.
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.
Validation of the Ncode column partially depends on the row's related SAMPLES.SType. The STYPES_NCODES table defines which SType values can be used with which Ncode values.
A unique integer which identifies the NEIGHBORS row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The POINT_DATA.Pntid of the point in which this neighbor was recorded. 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 BIOGRAPH.Sname of the neighbor.
This column must be NULL when the neighbor is an
unknown individual or otherwise not in BIOGRAPH, i.e. when the Unksname is not NULL.
The NCODES.Ncode describing the kind of neighbor represented in the row.
Some values from NCODES may be restricted, based on the sampling protocol. See STYPES_NCODES for more information.
This column may not be NULL.
The UNKSNAMES.Unksnamenature code recorded when the neighbor cannot be precisely identified[101].
This column must be NULL when the neighboring
individual is precisely identified, i.e. when the Sname is not NULL.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
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, FPOINTS, and NEIGHBORS tables, other information — normally collected ad-libitum during data collection — may be collected as well and are also associated with the specific sample. Further, a sample is allowed to contain no (animal) information.[102] 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 system will return a warning when the Date is before the focal individual's LatestBirth.
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.[103]
Other data integrity checks may be performed on a SAMPLES row — and on related rows in POINT_DATA, FPOINTS, and NEIGHBORS — depending on the data collection protocol used in the focal sample. Each sample's protocol is indicated by its SType, and the details of these other data integrity checks are defined in the STYPES table.
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.
Focal sampling protocols usually designate how many minutes should elapse in each sample, but for various reasons samples collected in the field may last for fewer than the expected number of minutes. Regardless of the expected number of elapsed minutes in a sample, the actual number and the number of those minutes in which a focal "point" was collected are recorded in the Mins and Minsis columns, respectively. Both of these integer columns cannot be less than zero. Their maximum allowed value depends on the row's SType and related STYPES.Max_Points.
The data collected during a focal sample are complex. To assist the observer with recording it all, these data are often though not always collected with an electronic device — e.g. a handheld phone/tablet — and specialized data collection software. This table uses three columns to record details about the hardware and software — or lack thereof — used for data collection: Collection_System, Programid, and Setupid. The Collection_System indicates the hardware used (e.g. "Samsung Tablet B", "Psion unit 6", "Pen and paper"). The Programid indicates the software that the hardware used, and the Setupid indicates any special configuration file(s) that the software used.
If a focal sampling arrangement has no particular need
for one of these columns — e.g. samples recorded with
a pen and paper likely won't need Programid nor Setupid
— do not set that column to NULL. Collection_System isn't allowed to be
NULL, and both Programid and
Setupid should only be NULL when
their true values are unknown. Instead, add a row to the
column's respective support table that essentially means
"N/A" and use that value in this table.
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.
This column cannot be changed and must not be
NULL.
The GROUPS.Gid of the focal individual's group, recorded at the time of data collection by the observer.
This column may not be NULL.
The STYPES.SType of the data collection protocol used in this focal sample.
This column may not be NULL.
The total number of minutes which actually elapsed while the sample was collected.
This column may not be NULL.
The actual number of point observations (once per minute) recorded during the sample.
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 column may not be NULL and must be less than
or equal to this row's Mins.
The SAMPLES_COLLECTION_SYSTEMS.Collection_System indicating how the sample's data were collected.
This column may not be NULL.
The PROGRAMIDS.Programid of the software ("program") used on this row's device to collect this sample's data.
This column may be NULL, indicating that this
information is unknown.
The SETUPIDS.Setupid representing the configuration ("setup") file(s) used by this row's software to collect the data in this sample.
This column may be NULL, indicating that this
information is unknown.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
[85] notably consortships
[86] There is no restriction on the age or maturity status of the female.
[87] This is not always as useful as it seems. See the rationale for the PARTS table.
[88] 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.
[90] and perhaps ejaculation
[91] Presumably data that is collected on a Psion or other electronic device.
[92] 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.
[93] 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.
[94] See the appendix: The All-Occurrences Focal Point Data.
[95] As opposed to recording the interaction with an electronic device.
[96] 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.
[97] 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.
[98] 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 it 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.
[99] 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.
[100] Assuming that the neighbor is a known individual, that
the NEIGHBORS.Sname column is not NULL.
[101] 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.
[102] 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.
[103] 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.
[104] 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.