Social And Multiparty Interactions

ACTIVITIES

The activities recorded in focal point observations.

Vocabulary For

ACTIVITIES defines values for the Activity of the POINT_DATA table and the Activity of the STYPES_ACTIVITIES table.

Key Name: Activity

Activity

Special Values

The value F has a special meaning to the system. It indicates feeding and triggers a required Foodcode in POINT_DATA.Foodcode.

ACTS (Interaction Types)

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.

Vocabulary For

ACTS defines values for the Act column of INTERACT_DATA.

Key Name: Act

Act

Special Values

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 Class column

The ACTS row of interaction classification. (See above.) This column may not be NULL.

The Retired column

A TRUE value in this column indicates that the Act value may not be used in new rows added to Babase. This column must contain either TRUE or FALSE.

DATA_STRUCTURES (Data structures produced by Psion devices)

One row for each version of data structure produced by Psion devices when exporting focal sampling data.

Note

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.

Vocabulary For

DATA_STRUCTURES defines vocabulary for SETUPIDS.Data_Structure.

Key Name: Data_Structure

Data_Structure

An integer.

Special Values

The Data_Structure value 1 is the data structure understood by the Psionload program.

CONTEXT_TYPES (multiparty Interaction Context Categories)

The social contexts in which multiparty interactions occur.

Vocabulary For

CONTEXT_TYPES defines values for MPIS.Context_type.

Key Name: Context_type

A 1 character code identifying the social context.

Special Values

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.

FOODCODES (Food item Codes)

The different food items eaten by baboons.

Vocabulary For

FOODCODES defines values for POINT_DATA.Foodcode.

Key Name: Foodcode

Foodcode

The Ftype column

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.

Special Values

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.

FOODTYPES (Food Types)

Food items are categorized into broader classifications using the codes defined on the FOODTYPES tables.

Vocabulary For

FOODTYPES defines vocabulary for the Ftype column of the FOODCODES table.

Key Name: Ftype

Ftype

Special Values

None.

KIDCONTACTS (spatial relationship between mother and infant)

The different spatial relationships between mother and infant recorded during adult female all-occurrences point sampling.

Vocabulary For

KIDCONTACTS defines vocabulary for the Kidcontact column of the FPOINTS table.

Key Name: Kidcontact

Kidcontact

Special Values

None.

MPIACTS (Multiparty Interaction Types)

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.

Note

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.

Vocabulary For

MPIACTS defines values for the MPIAct column of MPI_DATA.

Key Name: MPIAct

MPIAct

Special Values

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.

The Kind of act column

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.

The Decided column

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.

The Multi_first column

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.

NCODES (Neighbor classifications)

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.

Vocabulary For

NCODES defines vocabulary for the Ncode column of the NEIGHBORS table and the Ncode of the STYPES_NCODES table.

Key Name: Ncode

Ncode. The value of this column may not be changed.

Special Values

None.

Requires (Requires another neighbor)

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.

Nsex (Neighbor Sex requirement)

The sex that the neighbor must have. Possible values and their meanings:

The NCODES.Nsex Values
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.

Caution

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.

Nunique (Neighbor must be Unique)

A boolean indicating if the Sname used with this Ncode must be unique among all the neighbors of a particular point observation (NEIGHBORS.Pntid).

This column may not be NULL.

PARTUNKS (problem identifying a multiparty interaction participant)

The different reasons why a participant in a multiparty interaction is unable to be identified during data collection.

A Unksname value must not appear as a BIOGRAPH.Sname value.

Vocabulary For

PARTUNKS defines vocabulary for the Unksname column of the MPI_PARTS table. It is also used by the Upmpi program to test the uploaded data for unknown participants in a consortship interaction.

Key Name: Unksname

Unksname

Special Values

None.

POSTURES

The postures recorded in focal point observation.

Vocabulary For

POSTURES defines values for POINT_DATA.Posture and STYPES_POSTURES.Posture.

Key Name: Posture

Posture

Special Values

None.

PROGRAMIDS (Program used on the device)

One row for each version of each program used on a handheld data collection device.

Note

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.

Vocabulary For

PROGRAMIDS defines vocabulary for SAMPLES.Programid.

Key Name: Programid

Programid

An integer.

Special Values

None.

PID_String (ProgramID String)

The string the device reports as its program id.

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.

SAMPLES_COLLECTION_SYSTEMS

One row for each device or "system" used for collecting focal sample data.

Note

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.

Vocabulary For

SAMPLES_COLLECTION_SYSTEMS defines vocabulary for SAMPLES.Collection_System.

Key Name: Collection_System

Collection_System

An integer.

Special Values

None.

SETUPIDS (Setup files used in a data collection program)

One row for each configuration — which may represent one or more specific files — used in a program for data collection.

Note

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.

Note

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.

Note

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.

Warning

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.

Vocabulary For

SETUPIDS defines vocabulary for SAMPLES.Setupid.

Key Name: Setupid

Setupid

An integer.

Special Values

None.

SID_String (SetupID String)

The string the device reports as its setup id.

Data_Structure

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.

STYPES (Focal Sample Types)

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.

Vocabulary For

STYPES defines the vocabulary for the SAMPLES.SType, STYPES_ACTIVITIES.SType, STYPES_POSTURES.SType, and STYPES_NCODES.SType columns.

Key Name: SType

SType

Special Values

None.

Sex

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.

Max_Points

The maximum allowed number of points in a focal sample of this SType.

This column must be a positive integer and cannot be NULL.

Has_FPoints

A boolean indicating if focal samples of this SType can have related rows in FPOINTS.

This column may not be NULL.

Days_Before_Matured

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.

Days_After_Matured

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.

Req_Matured

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.

Days_Before_Ranked

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.

Days_After_Ranked

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.

Req_Ranked

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.

Days_Before_FirstBirth

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.

Days_After_FirstBirth

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.

Req_FirstBirth

A boolean, indicating whether focal individuals in samples of this SType are required to have a BIOGRAPH.Birth date of their first offspring. Or rather, whether the focal individuals in samples of this SType are required to have any offspring at all.

This column may not be NULL.

STYPES_ACTIVITIES (Activity values that are used with each SType)

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.

Tip

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.

Vocabulary For

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.

STypes_Activities Key

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.

Special Values

None.

SType

The STYPES.SType of the sample type in which this row's Activity is allowed to be used.

This column may not be NULL.

Activity

The ACTIVITIES.Activity that is allowed to be used with this row's SType.

This column may not be NULL.

STYPES_NCODES (Ncodes that are used with each SType)

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.

Tip

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.

Vocabulary For

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.

STypes_Ncodes Key

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.

Special Values

None.

SType

The STYPES.SType of the sample type in which this row's Ncode is allowed to be used.

This column may not be NULL.

Ncode

The NEIGHBORS.Ncode of the Ncode that is allowed to be used with this row's SType.

This column may not be NULL.

STYPES_POSTURES (Postures that are used with each SType)

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.

Tip

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.

Vocabulary For

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.

STypes_Postures Key

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.

Special Values

None.

SType

The STYPES.SType of the sample type in which this row's Posture is allowed to be used.

This column may not be NULL.

Posture

The POINT_DATA.Posture of the Posture that is allowed to be used with this row's SType.

This column may not be NULL.

SUCKLES (infant suckling activity)

Vocabulary describing the nature of an infant's suckling activity.

Vocabulary For

Suckles defines the vocabulary for the Kidsuckle column of the FPOINTS table.

Key Name: Suckle

Suckle

Special Values

None.



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


Page generated: 2024-05-31T10:38:02-04:00.