EATS contains one row for every different part of every kind of food eaten during a eating event. Each eating event, each EVENTS row having a Behavior value that designates eating, must have at least one related row on EATS[17], and may have more if different kinds of food or parts of food are eaten by the chimpanzee.
The combination of the kind of food eaten and the food part eaten must be unique per event -- the combination of EID, Foodkind, and Foodpart must be unique.
Aside from the EVENTS.Comment column there is no way to record the amount of any one of the different kinds of food or parts thereof eaten by the individual.
The system does not presently validate that the part eaten is appropriate for the kind of food eaten.[18] To the system, it is perfectly acceptable to eat the kidney of a tree. It may be prudent to manually validate the existing combinations before performing analysis.
A unique identifier assigned to the combination of kind of
food and part of food eaten during the given behavioral event.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the kind of food eaten and part of food eaten.
This column may not be NULL.
Code indicating a kind of food eaten during the event. The legal values for this column are defined by the FOODKINDS support table.
This column may not be NULL.
Code indicating the food part eaten during the event. The legal values for this column are defined by the FOODPARTS support table.
This column may not be NULL.
EVENTS contains one row for every recorded non-social
behavior exhibited by each focal as well as one row for every
recorded social behavior exhibited by each focal for every social
partner, for every follow interval. Each of the focal's
non-social behaviors for the interval are represented by a single
row per behavior in EVENTS. Each of the focal's social
behaviors for the interval are represented by a single row in
EVENTS per behavior per social partner.
These rules are enforced on transaction commit by ensuring that
the combination of EVENTS.Behavior, and
all related
BIOGRAPHY_DATA.AnimID
values, related via
PARTS.Participant, and
the roles the participating individuals play in the interaction,
the PARTS.Part values
are unique per EVENTS.IntID. The
exception is that anonymous individuals are allowed duplicates;
duplicates are allowed when EVENTS.Baboon
is TRUE or when one of the individuals involved has a
AnimID value which is
either UNK
or MGE.
Social behaviors are recorded as dyadic interactions between 2 individuals. Record multiple interactions as pairs of dyadic interactions. When directionality is involved, as in mutual grooming between 2 individuals, 2 grooming events are recorded, identical except for reversed directionality.
There must always be a chimpanzee involved in the behavior -- each EVENTS row must have at least one row on PARTS, related by EID. This rule is enforced on transaction commit.
At least one of the individuals involved in the behavior must be a focal of the follow -- at least one of the related PARTS rows must have a Participant value which identifies an animal also identified in one of the related FOLLOWPARTS.ChimpID values. This rule is enforced on transaction commit on PARTS, EVENTS, and FOLLOWPARTS, and immediately on INTERVALS.
The BEHAVIORS.Behavior value identifying the kind of behavior controls quite a lot regarding the event including: whether the behavior can occur, whether a Position value is required, the identity of the individuals allowed to be involved in the behavioral event, the fashion in which individuals are allowed to participate, and whether the behavior is a social one -- whether more than one individual is involved -- and whether a baboon can be involved. For further information see the BEHAVIORS table.
When the behavior is social, recording a dyadic interaction
between two individuals, and one of the two individuals involved
plays the active part, has a
PARTS.Part value
of R (Actor), then the other
individual must have the passive role, their
PARTS.Part value must
be E (Actee); and the reverse is true
as well. Social interactions may be non-directional as well as
directional. When there is no directionality the individuals
involved in the interaction are both
labeled “participant” -- when the behavior is social
and one of the individuals has a
PARTS.Part value
of P (Participant) then the
other individual must also have a
PARTS.Part value
of P. These rules are check
upon transaction commit.
EVENTS rows recording behaviors that are social in nature are always dyadic, there must always be two related PARTS rows to record the two participants involved. The exception to this is when one of the participants is a baboon. In this case there is a single related PARTS row recording which focal is involved in the interaction and the EVENTS.Baboon column is set to indicate the baboon's involvement. This rule is enforced on transaction commit.
The individual involved in those EVENTS rows recording
behaviors which are not social, those where there is a single
individual involved in the behavior, those having a single related
PARTS row, cannot be directional, their related
related PARTS row must have a
PARTS.Part value
of S (Self). Further, a baboon may
not be involved, EVENTS.Baboon must be
FALSE. These rules are checked upon transaction
commit.
Deleting a row from the EVENTS table will delete the entire event -- the system will first delete all related PARTS, EATS, FISHED, PLAYS, RESTS, RIDES, and VOCS rows.
A unique identifier assigned to each behavioral
event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the follow interval, the INTERVALS.IntID, value, related to the occurrence of the recorded behavior.
This column may not be NULL.
Code indicating the behavior engaged in. The legal values for this column are defined by the BEHAVIORS support table.
This column may not be NULL.
Code indicating the position within the forest canopy where the event occurred. The legal values for this column are defined by the POSITIONS support table.
This column may not be NULL.
A Boolean value. When TRUE a baboon is a participant in
the behavior. When FALSE a baboon is not a
participant.
This column may not be NULL.
A Boolean value. When TRUE the recorded behavior is in
doubt.[19] When FALSE the recorded behavior was clearly
observed and is not in doubt. See the Gombe
Chimp Database Handbook for further
information.
This column may not be NULL.
Textual comments concerning the specific behavioral event. These comments are those of the data collector in the field.
This column may not be empty, it must contain characters,
and it must contain at least one non-space character. However, the Comment value may be NULL when
there are no comments concerning the event.
FISHED contains one row to record the part and the kind of food fished for during each fishing event. Each fishing event, each EVENTS row having a Behavior value that designates fishing, must have exactly one related row on FISHED[20], and may have more if different kinds of food are fished for by the chimpanzee.
Only those kinds of food designated
as “fishable” may be fished for --
FISHED.Foodkind may contain only those
FOODKINDS.Foodkind
values where the related
FOODKINDS.Fishable
value is TRUE.
Only those parts of food designated
as “fishable” may be fished for --
FISHED.Foodpart may contain only those
FOODPARTS.Foodpart
values where the related
FOODPARTS.Fishable
value is TRUE.
The system does not presently validate that the part fished for is appropriate for the kind of food fished for. It may be prudent to manually validate the existing combinations before performing analysis.
A unique identifier assigned to the kind of food fished
for during the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the kind of food fished for.
This column may not be NULL.
Code indicating a kind of food fished for during the event. The legal values for this column are defined by the FOODKINDS support table.
This column may not be NULL.
Code indicating the food part fished for during the event. The legal values for this column are defined by the FOODPARTS support table.
This column may not be NULL.
PARTS contains one row for every individual, whether a focal
in the follow or not[21], involved in each recorded behavior (each
EVENTS row). Therefore there are always
either 1 or 2 PARTS rows per EVENTS row.
Individuals which are unrecognized or otherwise anonymous, the
individuals with AnimID values
of UNK
or MGE, have rows in PARTS when
they are involved in the behavior, but baboons do not.
An individual can be involved in a given behavioral event only once -- the related BIOGRAPHY_DATA.AnimID must be unique per EID.
Each participant in an event must be a member of the study population on the date of the follow. The BIOGRAPHY_DATA.Entrydate cannot be after the follow's FOLLOWS.Date value. The BIOGRAPHY_DATA.Departdate cannot be before the follow's FOLLOWS.Date.
A unique identifier assigned to the individual involved in
the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the recorded participant.
This column may not be NULL.
One of the following codes indicating the role the designated individual plays in the behavior:
R (Actor)
The individual has the active role in the behavior, initiating or sustaining it.
E (Actee)
The individual has the passive role in the behavior, receiving attention or contact.
P (Participant)
The individual is neither active nor passive, such concepts do not apply or are not appropriate to the behavior or the data collection protocol.
S (Self)
The individual is the sole participant in the behavior.
This column may not be NULL.
The identifier assigned to the individual involved in the behavior. The ChimpID code of the individual.
This column may not be NULL.
PLAYS contains one row for every different play activity engaged in during a play event. Each play event, each EVENTS row having a Behavior value that designates a play type event, must have at least one related row on PLAYS[22], and may have more if the playing chimpanzee engages in different play activities during the play event.
The play activity must be unique per event -- the combination of EID and Play must be unique.
Aside from the EVENTS.Comment column there is no way to record the number or duration of any one of the different play activities engaged in by the individual during the play event.
A unique identifier assigned to the play activity engaged
in during the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the play activity.
This column may not be NULL.
Code indicating a play activity engaged in during the event. The legal values for this column are defined by the PLAY_TYPES support table.
This column may not be NULL.
RESTS contains one row to record the resting posture assumed during each resting event. Each resting event, each EVENTS row having a Behavior value that designates a resting type event, must have exactly one related row on RESTS.[23]
Aside from the EVENTS.Comment column there is no way to record the duration of the resting posture assumed by the individual during the resting event.
A unique identifier assigned to the resting posture
assumed during the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the resting posture assumed.
This column may not be NULL.
Code indicating a resting posture assumed during the event. The legal values for this column are defined by the RESTING_POSTURES support table.
This column may not be NULL.
RIDES contains one row which records the riding posture assumed during each riding event. Each riding event, each EVENTS row having a Behavior value that designates a riding type event, must have exactly one related row on RIDES.[24]
Aside from the EVENTS.Comment column there is no way to record duration of the riding posture assumed by the individual during the riding event.
A unique identifier assigned to the riding posture
assumed during the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the riding posture assumed.
This column may not be NULL.
Code indicating a riding posture assumed during the event. The legal values for this column are defined by the RIDING_POSTURES support table.
This column may not be NULL.
VOCS contains one row for every different kind of vocalization made during a vocalization event. Each vocalization event, each EVENTS row having a Behavior value that designates a vocalization, must have at least one related row on VOCS[25], and may have more if different kinds of vocalizations are made by the vocalizing chimpanzee.
The kind of vocalization must be unique per event -- the combination of EID and Vocalization must be unique.
Aside from the EVENTS.Comment column there is no way to record the number or volume of any one of the different kinds of vocalizations made by the individual during the vocalization event.
A unique identifier assigned to the kind of vocalization
made in the given behavioral event. This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
The identifier assigned to the behavioral event, the EVENTS.EID, value, related to the kind of vocalization made.
This column may not be NULL.
Code indicating a kind of vocalization made as the event occurred. The legal values for this column are defined by the VOCALIZATIONS support table.
This column may not be NULL.
[17] If the food eaten is unknown this should be indicated with a FOODKINDS code which designates an unknown food. Likewise, if the part of the food eaten is unknown indicate this with a FOODPARTS code which designates that the part is unknown.
[18] While this is not hard to do this kind of validation is not a priority.
[19] Note that the system contains no way to designate that the identity of a participant in the behavior is uncertain.
[20] If the food fished for is unknown this should be indicated with a FOODKINDS code which designates an unknown food. Likewise, if the part of the food fished for is unknown indicate this with a FOODPARTS code which designates that the part is unknown.
[21] An improved design would have an additional column, automatically maintained by the system, on PARTS to record the role the participant plays in the follow, i.e., mother, infant, sib, or non-focal. This would be analogous to the DISTANCEPARTS.Role column. Such a column would simplify both the data validation coding and database querying. See also the footnote regards improving the DISTANCEPARTS design.
[22] If the play activity occurring is unknown this should be indicated with a PLAY_TYPES code which designates an unknown play activity.
[23] If the resting posture assumed is unknown this should be indicated with a RESTING_POSTURES code which designates an unknown resting posture.
[24] If the riding posture assumed is unknown this should be indicated with a RIDING_POSTURES code which designates an unknown riding posture.
[25] If the vocalization made is unknown this should be indicated with a VOCALIZATIONS code which designates an unknown vocalization.