Social and Multiparty Interactions

ALLMISCS (Ad-libitum sample data)

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.

Note

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.

Note

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.

Warning

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.

Almid (Allmiscs IDentifier)

A unique integer which identifies the ALLMISCS row.

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

Sid (Sample Identifier)

The focal point data set in which the data were collected. (See SAMPLES.Sid.)

Atime (time)

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.

Txt (unstructured Text)

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

CONSORTS (multiparty disputes over CONSORTshipS)

One row for every MPIS row (multiparty interaction) involving a consortship. This table extends the MPIS table to include information about consortships.[86]

Mpiid (Multiparty Interaction IDentifier)

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.

Female

The disputed female. A BIOGRAPH.Sname of a female.

This column may be NULL when the consorted female is unrecorded.

Had

The male who consorted with the female prior to the multiparty interaction. A BIOGRAPH.Sname of a male.

This column may not be NULL.

Got

The male who consorted with the female after the multiparty interaction. A BIOGRAPH.Sname of a male.

This column may not be NULL.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

FPOINTS (Point data on Females)

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.

Note

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.

Tip

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.

Pntid (Point Identifier)

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.

Kidcontact (female/infant position)

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.

Kidsuckle (Suckling activity)

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

INTERACT_DATA (Interactions)

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.

Warning

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.

Tip

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.

  • The Date cannot be after a participant's Statdate.

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

Tip

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.

Note

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.

Caution

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.

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.

Column Descriptions

Iid

A positive integer that uniquely identifies the interaction. This number is assigned by the system. This column must not be NULL.

Sid (all-occurrences Sample IDentifier)

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.

Act (kind of interaction)

A code indicating the kind of interaction. The ACTS support table defines the legal values for this column.

Note

Although Act contains ACTS.Act values, it is often the broader ACTS.Class classification that is of interest.

This column may not be NULL.

Date

The date on which the interaction took place. This column may not be NULL.

Start (interaction Starting time)

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.

Stop (interaction ending time)

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.

Observer

The OBSERVERS.Initials of the person who recorded this interaction.

This column may be NULL.

Handwritten

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.

Exact_Date

A boolean indicating whether or not the Date is the specific date of the interaction.

This column defaults to TRUE, and cannot be NULL.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

MPIS (Multiparty InteractionS)

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.

Note

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.

Mpiid (Multiparty Interaction IDentifier)

A unique integer which identifies the MPIS row.

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

Date

The date the interactions occurred.

Context_type

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.

Context (Unstructured text)

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

MPI_DATA (Multiparty dyadic Interactions)

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.

Tip

The MPI_EVENTS view provides a convenient way to view multiparty interactions as single rows.

Caution

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.

Mpidid (Multiparty Interaction Data IDentifier)

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.

Mpiid (Multiparty Interaction IDentifier)

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.

MPIAct (Multiparty Interaction Act code)

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.

Seq (Sequence)

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.

Note

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.

Helped

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.

Active

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.

Caution

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

MPI_PARTS (Multiparty Interaction PARTicipantS)

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.

Tip

The MPI_EVENTS view provides a convenient way to view multiparty interactions as single rows.

Warning

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.

Caution

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.

Mpipid (Multiparty Interaction Participant IDentifier)

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.

Mpidid (Multiparty Interaction Data IDentifier)

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.

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information, 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.

Unksname (Unknown neighbor code)

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.

Role

This column designates whether the row records the actor or the actee of the interaction. The two possible values are:

The MPI_PARTS.Role Values
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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

PARTS (Participants in interactions)

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.

Caution

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.

Caution

The data integrity rules require that the INTERACT_DATA row be entered before the 2 PARTS rows.

Tip

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.

Note

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.

Partid (Parts IDentifier)

A unique integer which identifies the PARTS row.

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

Sname

A three-letter code (an id) that uniquely identifies a particular animal (an Sname) in BIOGRAPH. This code can be used to retrieve information, 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.

Role

This column designates whether the row records the actor or the actee of the interaction. The two possible values are:

The PARTS.Role Values
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.

Iid (Interaction identifier)

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

POINT_DATA (Point observation data)

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.

Warning

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.

Pntid (Point observation Identifier)

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.

Sid (Sample Identifier)

The SAMPLES.Sid of the focal sample during which this point was collected.

This column may not be NULL.

Min (Point number within the sample)

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.

Ptime (Point observation Time)

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]

Warning

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.

Activity

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.

Posture

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.

Foodcode (May 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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

NEIGHBORS (point observation data on Neighbors)

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.

Nghid (Neighbors IDentifier)

A unique integer which identifies the NEIGHBORS row.

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

Pntid (Point Identifier)

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.

Sname

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.

Ncode (code classifying the kind of neighbor)

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.

Unksname (Unknown neighbor code)

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.

Sys_Period

The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.

SAMPLES (all-occurrences Samples)

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.

Tip

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.

Column Descriptions

Sid (Sample Identifier)

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.

Date

The date of the focal sample[104].

This column may not be NULL.

Stime (time sampling began)

The time the sampling began.

This column may not be NULL.

Grp (Group observed)

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.

Sname

The BIOGRAPH.Sname of the focal individual.

This column may not be NULL.

SType (Sample Type)

The STYPES.SType of the data collection protocol used in this focal sample.

This column may not be NULL.

Mins (Minutes elapsed)

The total number of minutes which actually elapsed while the sample was collected.

This column may not be NULL.

Minsis (Minutes In Sight)

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.

Observer

The OBSERVERS.Initials of the person who collected the sample.

This column may not be NULL.

Collection_System

The SAMPLES_COLLECTION_SYSTEMS.Collection_System indicating how the sample's data were collected.

This column may not be NULL.

Programid

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.

Setupid

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.

Sys_Period

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.

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


Page generated: 2024-05-31T10:37:54-04:00.