The activities recorded in focal point observations.
ACTIVITIES defines values for the Activity of the POINT_DATA table and the Activity of the STYPES_ACTIVITIES table.
The value F has a
special meaning to the system. It indicates feeding and
triggers a required Foodcode in
POINT_DATA.Foodcode.
The different kinds of (non-multiparty) interactions between individuals which may be recorded.
The various kinds of interactions may be grouped together into larger categories, which are themselves valid kinds of interactions. The Class column is used for this purpose. The Class column contains an Act value identifying the larger class of interactions to which the interaction belongs. If the interaction does not belong to a larger category, the Class should contain the row's own Act value. Only 1 level of classification hierarchy is allowed -- the ACTS row referenced in the Class column must have a Class value equal to its Act value.
Rows that contain a TRUE value in the Retired column
may not be referred to by newly created database rows,
although, presumably older, pre-existing rows may contain the
Act values of these retired rows. Should it be necessary to
create such new rows, retired ACTS may be temporarily
un-retired.
ACTS defines values for the Act column of INTERACT_DATA.
All of the Class codes on ACTS have a special meaning to the system's programs. New Class codes may not be created and rows that represent the classifications, have an Act equal to their Class, cannot have their Act, Class, or Descr values changed.[234]
The ACTS row of interaction classification. (See
above.) This column may not be NULL.
One row for each version of data structure produced by Psion devices when exporting focal sampling data.
The primary purpose of this table is to ensure that the data coming off a Psion unit is correctly interpreted by the Psionload program and loaded into the right tables. The structure and semantics of data collected by a Psion unit is determined by the setup file, but various setup files can produce the same output.
See below for information about the relevance of these values to focal data that did not come from a Psion device.
For further comments, see SETUPIDS.
DATA_STRUCTURES defines vocabulary for SETUPIDS.Data_Structure.
The Data_Structure value
1 is the data
structure understood by the Psionload
program.
The social contexts in which multiparty interactions occur.
CONTEXT_TYPES defines values for MPIS.Context_type.
Special CONTEXT_TYPES
N
No context. The MPIS.MPIS-Context column must be NULL when
this code is used.
C
Consortship. The multiparty interaction occurred in the context of a consortship.
The MPIS.MPIS-Context column must be NULL when
this code is used. The MPIS.Context_type column must be
C when a related
CONSORTS row exists. The system
will generate a warning when the MPIS.Context_type
column is C and
there is no related CONSORTS
row.
The different food items eaten by baboons.
FOODCODES defines values for POINT_DATA.Foodcode.
Food items are themselves categorized into types. This column contains the type of the food item. Valid food type values are those stored in the FOODTYPES.Ftype column.
There are no special FOODCODE values, however it is
worth remarking on the POINT_DATA.Activity
F value, which has
special meaning to the system. The POINT_DATA.Foodcode
column must contain a value when and only when POINT_DATA.Activity
is F, otherwise POINT_DATA.Foodcode
must be NULL.
Food items are categorized into broader classifications using the codes defined on the FOODTYPES tables.
The different spatial relationships between mother and infant recorded during adult female all-occurrences point sampling.
KIDCONTACTS defines vocabulary for the Kidcontact column of the FPOINTS table.
The different kinds of dyadic interactions which may be recorded as interactions occurring during a multiparty interaction event. There are 4 mutually exclusive categories of interactions: Agnoisims, Requests for help, Help given, and Other.
The Decided column cannot be TRUE unless the kind of
the act is an agonism -- the Kind column is
A.
Because the first interaction of a multiparty
interaction must be an agonism Multi_first cannot be TRUE
unless Kind is A.
Although Babase stores multiparty interactions using a data structure similar to that used to store non-multiparty interactions the data sets are separate, different kinds of interactions are recorded using different codes, and the interactions are never recorded in both data sets.
The value AH must be
the code used to indicate the giving of active help. The
value PH must be the code
used to indicate the giving of passive help. These codes
are tested for in the process of generating warnings
indicating that the MPI_DATA.Active value may be incorrect.
Some values have special meaning to the Upmpi program, in that the program changes act values in the uploaded file to particular values. See the documentation on this for more detail.
This column classifies the kind of interaction into one of 4 distinct types, as listed below.
MPIACTS.Kind values
A
An Agonism interaction.
R
A Request for help.
H
Help given.
O
Other.
This column may not be NULL.
A TRUE value in this column indicates that the
action was an agonism resulting in a definite winner and
loser, FALSE indicates otherwise.
This column may not be NULL.
A TRUE value in this column indicates that the MPIAct code can be used as a MPI_DATA.MPIAct value
when there is more than one MPI_DATA row
for a multiparty interaction having a Seq value of 1 --
such interactions which initiate a collection of multiparty
interactions need not be dyadic, they can occur between more
than 2 individuals.[235] All other interactions (those where Multi_first
is FALSE) which begin a collection of multiparty
interactions (those having a Seq
value of 1) must involve just 2
individuals.
This column may not be NULL.
The different classifications of neighbor recorded during focal point observations.
The Requires, Nsex, and Nunique columns allow for some more complicated validation of Ncode use in NEIGHBORS, as discussed below.
When neighbors should be recorded in a specific order,
the Requires column ensures that they
are. When there is a value in this column, the row's Ncode
cannot be used as a NEIGHBORS.Ncode for the point observation (the
NEIGHBORS.Pntid)
unless that point already has another NEIGHBORS row with this NCODES row's Requires. For example, suppose Ncode
2 indicates the second nearest neighbor and
Ncode 1 is the nearest neighbor[236]. When Ncode 1 is placed in
Ncode 2's Requires column, Babase will not
allow a point observation to have a second nearest neighbor
(Ncode 2) unless there is already a nearest
neighbor (Ncode 1).
The Nsex column is used to enforce that a neighbor must be a particular sex. This is complicated because it may rely on the sex of the neighbor with the Ncode specified in the Requires column, as discussed below.
An NCODES row may not have a Requires of NULL and a Nsex value of
O.
In some sampling protocols, one individual might be the
appropriate Sname for more than
one Ncode. In other cases, it may be preferable to enforce
that all neighbors recorded in a point observation be
distinct. This type of validation is controlled by the
boolean Nunique column. When TRUE,
the Sname must be unique among all
the neighbors of a particular point observation (NEIGHBORS.Pntid).
When FALSE, the Sname need not
be unique.
NCODES defines vocabulary for the Ncode column of the NEIGHBORS table and the Ncode of the STYPES_NCODES table.
Another Ncode, representing the neighbor type that must be recorded in a point observation before this row's Ncode can be recorded with that observation.
This column may be NULL, in which case the only
requirement is that the same Ncode not be used twice in one
point observation.
The sex that the neighbor must have. Possible values and their meanings:
| Code | Mnemonic | Definition |
|---|---|---|
| A | Any | The neighbor with this Ncode may be of any sex. |
| M | Male | The neighbor with this Ncode must be male.[237] |
| O | Opposite | The neighbor with this Ncode must be of a different sex than the neighbor with the Requires Ncode. Note that because there are 3 sexes — male, female, and unknown — this does not strictly conform with the field monitoring guide which only takes males and females into account. If this is a problem then we need to do something about it. |
Neighbors with a Unksname rather than a Sname are always considered to be of
the opposite sex — they satisfy the
O Nsex code.
This column may not be NULL.
The different reasons why a participant in a multiparty interaction is unable to be identified during data collection.
The postures recorded in focal point observation.
POSTURES defines values for POINT_DATA.Posture and STYPES_POSTURES.Posture.
One row for each version of each program used on a handheld data collection device.
The primary purpose of this table is to avoid storing relatively lengthy identical strings on the SAMPLES table. This table would probably not be worth having were not the program ID strings reported by the devices so long, and did we not need the SETUPIDS table, which is very similar to this table.
One row for each device or "system" used for collecting focal sample data.
Originally, this table explicity listed only Psion focal sampling units and was named “PALMTOPS”. (At the time, that name was presumed to be an appropriately generic description for any kind of mobile electronic device.) In Babase 5.5.2, the table was renamed because 1) the term “palmtop” comes from another era and has little to no meaning for modern users, and more importantly 2) in preparation for the expected addition of focal data that were collected with only a pen and paper, the name needed to be changed to be more inclusive anyway. Ideally, the PALMTOPS_HISTORY table should have remained in the babase_history schema so that changes to it would remain accessible. However, when this table was renamed the PALMTOPS_HISTORY table was empty. There were no archived changes that needed to be preserved, so the PALMTOPS_HISTORY table was not retained.
SAMPLES_COLLECTION_SYSTEMS defines vocabulary for SAMPLES.Collection_System.
One row for each configuration — which may represent one or more specific files — used in a program for data collection.
Although not every setup file can be used with every version of every program, Babase makes no attempt to validate the setup files against the program files, or vice versa. This is because the data are expected to be generated by the programs and, unless they lie about the program they are running and the setup file used, whatever program id is reported must, ipso facto, work with the reported setup file.
The primary purpose of this table is to ensure, via its relation with the DATA_STRUCTURES table, that the data coming off the device is correctly interpreted by the Psionload program and loaded into the right tables. The table also allows Babase to save space on the SAMPLES table by storing the small Setupid integer rather than the relatively long setup ID strings reported by the devices.
The Data_Structure column is only used by the Psionload program. When a Setupid appears in SAMPLES with a Collection_System that is not a Psion device, its data are not expected to be imported via the Psionload program so the Setupid's Data_Structure value is irrelevant.
The system makes no attempt to validate the Data_Structure against the Collection_System for the reasons discussed above, not to mention that Psion units and the Psionload program are legacy systems with no modern use.
The setupid should determine the structure and semantics of the device's data files. If this assumption is violated, e.g. by having two different Psion programs produce different results from the same setup file, then the Psionload program may do bad things to the database.
For further comments, see PROGRAMIDS.
The DATA_STRUCTURES.Data_Structure indicating the version of the data structure produced by devices using the setup file.
This column may not be NULL.
The different focal sampling protocols used, including several columns that indicate how a sample's data should be validated.
The Sex column indicates if
this row's sampling protocol is specific to individuals of a
particular Sex. When this column
is not NULL, SAMPLES rows with this SType must have an Sname of an individual whose BIOGRAPH.Sex matches
this row's Sex.
The Max_Points column indicates the maximum number of points that are allowed to be recorded for a sample with this SType. All SAMPLES rows with this SType must have Mins and Minsis values less than or equal to this value.
The Has_FPoints column
indicates if points from samples with this SType are allowed
to include data about the focal individual's infant. When
TRUE, a SAMPLES row with this SType can have its related Pntid's in FPOINTS.
Many focal sampling protocols are explicitly targeted toward individuals of a specific age class, e.g. "adults" or "juveniles". Validating that an individual is in a particular age/sex class usually involves comparing the SAMPLES.Date to a certain "milestone" date in the individual's life, e.g. their MATUREDATES.Matured or RANKDATES.Ranked. For various reasons it is often desirable to allow some "wiggle room" when using these dates. For example, if males are considered "adults" on or after their RANKDATES.Ranked then a rule could be made requiring that samples on "adult males" must never be before the focal individual's Ranked date, but instead it may be preferable to allow samples on "adult males" to be some small period of time before his Ranked date. This table includes several columns that enable that kind of validation.
For each "milestone" date of interest, there is a Days_Before_Xxx column, a Days_After_Xxx column, and a Req_Xxx column. Validation related to the MATUREDATES.Matured is enabled using the Days_Before_Matured, Days_After_Matured, and Req_Matured columns; validation related to the RANKDATES.Ranked is enabled using the Days_Before_Ranked, Days_After_Ranked, and Req_Ranked columns; and validation related to the BIOGRAPH.Birth date of a female's first offspring is enabled using the Days_Before_FirstBirth, Days_After_FirstBirth, and Req_FirstBirth columns.
A Days_Before_Xxx column contains an integer that
indicates the maximum number of days before the Xxx date on
which a focal sample may occur with the indicated SType. E.g.
a row's Days_Before_Matured is some
number n, indicating that the Date of all SAMPLES rows
with this row's SType cannot be more
than n days before the focal individual's
Matured date[238].
A Days_After_Xxx column contains an integer that
indicates the maximum number of days after the Xxx date on
which a focal sample may occur with the indicated SType. E.g.
a row's Days_After_Matured is some
number n, indicating that the Date of all SAMPLES rows
with this row's SType cannot be more
than n days after the focal individual's
Matured date[239].
In many cases, the individual will not have a
"milestone" date in the database for legitimate
reasons[240]. Because of this, the Days_Before_Xxx and
Days_After_Xxx columns will not provoke an error when the
focal individual does not have an Xxx date. However, for some
sampling protocols it may be desirable to
require that the focal individual have an
Xxx date. This requirement can be toggled via the Req_Xxx
column. E.g. when the Req_Matured
column is TRUE, a SAMPLES row with this
SType must have an Sname that appears in the MATUREDATEStable.
Presumably, a focal sampling protocol that requires a
certain "milestone" date will likely also have some rules
using that date to validate the sample's Date. The system will return a warning
for any STYPES rows with a TRUE Req_Xxx but whose related
Days_Before_Xxx and Days_After_Xxx columns are NULL.
STYPES defines the vocabulary for the SAMPLES.SType, STYPES_ACTIVITIES.SType, STYPES_POSTURES.SType, and STYPES_NCODES.SType columns.
The required BIOGRAPH.Sex of all focal individuals with this SType.
This column may be NULL, indicating that this SType
does not require that the focal individual be a specific
sex.
The maximum allowed number of points in a focal sample of this SType.
This column must be a positive integer and cannot be
NULL.
A boolean indicating if focal samples of this SType can have related rows in FPOINTS.
This column may not be NULL.
A non-negative integer, indicating the largest number of days before the focal individual's MATUREDATES.Matured (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days before the focal
individual's Matured
date.
A non-negative integer, indicating the largest number of days after the focal individual's MATUREDATES.Matured (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days after the focal
individual's Matured
date.
A boolean, indicating whether focal individuals in samples of this SType are required to have a MATUREDATES.Matured date.
This column may not be NULL.
A non-negative integer, indicating the largest number of days before the focal individual's RANKDATES.Ranked (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days before the focal
individual's Ranked date.
A non-negative integer, indicating the largest number of days after the focal individual's RANKDATES.Ranked (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days after the focal
individual's Ranked date.
A boolean, indicating whether focal individuals in samples of this SType are required to have a RANKDATES.Ranked date.
This column may not be NULL.
A non-negative integer, indicating the largest number of days before the BIOGRAPH.Birth of the focal individual's first offspring (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days before the Birth of the focal individual's first
offspring.
A non-negative integer, indicating the largest number of days after the BIOGRAPH.Birth of the focal individual's first offspring (if any) on which focal samples of this SType are allowed.
This column may be NULL, indicating that samples
with this SType can be any number of days after the Birth of the focal individual's first
offspring.
Vocabulary describing which Activity values are allowed to be used with each SType. There is one row for each Activity allowed to be used with each SType.
Unlike most other support tables, this table does not have a Descr column. This table exists only to define vocabulary, so the meaning or "description" of each row is fully explained by the values in the SType and Activity columns.
Each SType-Activity dyad must be unique.
This table is important for data management but has little or no practical use for regular database users. If you are not a data manager, it is probably safe for you to ignore this table altogether.
STYPES_ACTIVITIES defines the vocabulary for the use of two separate columns in separate but related tables: SAMPLES.SType and POINT_DATA.Activity.
Each of those columns has its own support table controlling the vocabulary for its respective column (SType has STYPES, Activity has ACTIVITIES), but this table defines how those columns' values are allowed to be used together.
This table does not use a single column as its key. Instead, the key is the combination of SType and Activity. Those columns' separate values are the ones used in SAMPLES and POINT_DATA, so there is no utility gained from creating a separate "key" column here.
The STYPES.SType of the sample type in which this row's Activity is allowed to be used.
This column may not be NULL.
The ACTIVITIES.Activity that is allowed to be used with this row's SType.
This column may not be NULL.
Vocabulary describing which Ncodes are allowed to be used with each SType. There is one row for each Ncode allowed to be used with each SType.
Unlike most other support tables, this table does not have a Descr column. This table exists only to define vocabulary, so the meaning or "description" of each row is fully explained by the values in the SType and Ncode columns.
Each SType-Ncode dyad must be unique.
This table is important for data management but has little or no practical use for regular database users. If you are not a data manager, it is probably safe for you to ignore this table altogether.
STYPES_NCODES defines the vocabulary for the use of two separate columns in separate but related tables: SAMPLES.SType and NEIGHBORS.Ncode.
Each of those columns has its own support table controlling the vocabulary for its respective column (SType has STYPES, Ncode has NCODES), but this table defines how those columns' values are allowed to be used together.
This table does not use a single column as its key. Instead, the key is the combination of SType and Ncode. Those columns' separate values are the ones used in SAMPLES and NEIGHBORS, so there is no utility gained from creating a separate "key" column here.
Vocabulary describing which Postures are allowed to be used with each SType. There is one row for each Posture allowed to be used with each SType.
Unlike most other support tables, this table does not have a Descr column. This table exists only to define vocabulary, so the meaning or "description" of each row is fully explained by the values in the SType and Posture columns.
Each SType-Posture dyad must be unique.
This table is important for data management but has little or no practical use for regular database users. If you are not a data manager, it is probably safe for you to ignore this table altogether.
STYPES_POSTURES defines the vocabulary for the use of two separate columns in separate but related tables: SAMPLES.SType and POINT_DATA.Posture.
Each of those columns has its own support table controlling the vocabulary for its respective column (SType has STYPES, Posture has POSTURES), but this table defines how those columns' values are allowed to be used together.
This table does not use a single column as its key. Instead, the key is the combination of SType and Posture. Those columns' separate values are the ones used in SAMPLES and POINT_DATA, so there is no utility gained from creating a separate "key" column here.
The STYPES.SType of the sample type in which this row's Posture is allowed to be used.
This column may not be NULL.
The POINT_DATA.Posture of the Posture that is allowed to be used with this row's SType.
This column may not be NULL.
Vocabulary describing the nature of an infant's suckling activity.
[234] Except by suitably privileged individuals. See Special Values.
[235] Although they are still recorded as dyadic pairs,
there can be more than one pair with a sequence number
of 1
[236] As is indeed the case as of this writing.
[237] There is no code for female because at present the protocols do not require one.
[238] ...but can be any number of days after it.
[239] ...and also allows any number of days before it.
[240] For example, perhaps the individual has no MATUREDATES.Matured because they are young and haven't yet matured, or they're a male who dispersed or died before maturity.