A summary of paternity analyses. Contains one row for each offspring having a paternity analysis.

The Kid value must be unique -- there can be at most 1 row on DAD_DATA per offspring. The BIOGRAPH row related to the Kid must have a non-NULL Birth -- the offspring must be born.

There can be information as to whether the mother has been genetically sampled (there can be a non-NULL Mom_sampled) if and only if the mother is known (BIOGRAPH.Pid of the Kid is non-NULL). The system will report an error when this is not the case. The system will not allow changes to Mom_sampled that violate this rule but does allow changes to BIOGRAPH.Pid that violate this rule. It is assumed that any inconsistencies introduced in this fashion are only temporary and will be fixed soon when the related Mom_sampled value is updated.

There can be information as to whether the father has been genetically sampled (there can be a non-NULL Dad_sampled) if and only if the father is known (Dad_consensus is not NULL).

The number of potential dads genotyped (Pdads_typed) must not be larger than the number of potential dads considered (Pdads_considered). This number must be 0 or larger.

The columns identifying potential dads, Dad_excl, Dad_1perr, Dad_5perr, Dad_allmales, and Dad_consensus are subject to a number of data integrity checks, as follows: The individual must be male. If the mother is known he must be alive during the mother's fertile period -- the male's BIOGRAPH.Statdate must be on or after the mother's Zdate minus the 5 day fertile period, minus an additional 14 days to allow for interpolation if the male is alive. If the mother is known the male must be mature before the conception date -- the male must have a row in MATUREDATES and MATUREDATES.Matured must be before the Zdate. The system will report a warning if the male is not in the mother's supergroup at any time during the fertile period.

The Loci_excl column must be NULL if the Dad_excl column is NULL. Otherwise Loci_excl must be non-NULL.

The Conf_1perr column must be NULL if the Dad_1perr column is NULL. Otherwise Conf_1perr must be non-NULL.

The Conf_5perr column must be NULL if the Dad_5perr column is NULL. Otherwise Conf_5perr must be non-NULL.

The Conf_allmales column must be NULL if the Dad_allmales column is NULL. Otherwise Conf_allmales must be non-NULL.

The Date must be on or after the offspring's BIOGRAPH.Birth date.

The Dad_consensus may not have been a perfect choice, but merely the best option; for many reasons, the genotypes of the offspring, mom, and consensus dad may conflict, or “mismatch”. These mismatches do not mean that the Dad_consensus is invalid. The reasons for these mismatches are known (e.g. quality of tissue samples, technological limitations) and are considered when doing the paternity analyses. A Dad_consensus is provided only when the user is reasonably confident of its accuracy, regardless of any mismatches recorded in Consensus_Mismatch.

The offspring's Consensus_Mismatch can be NULL only when the Dad_consensus is also NULL.

A Completeness score for an offspring's paternity assignment is also given. This score is a categorical expression of how much is known about the genotypes of the offspring, mother, and potential dads, as well as how much more information is expected to be gained in the future. The Completeness for an offspring with few Pdads_typed, for example, depends on whether the untyped potential dads are still alive and available for further sampling. If all potential dads are dead, then no further information is likely to arise to inform this assignment and it is probably as “complete” as it will ever be. If several untyped potential dads are still alive, then the assignment has the potential to change in the future and should have a different Completeness score.

The group membership table. This table records which group each animal is in on which date, excepting fetal losses (individuals with no Sname). There is a row in MEMBERS for every individual for every day between Birth and Statdate, inclusive, including periods during which the whereabouts of an individual are either recorded as being unknown or assumed unknown by the interpolation procedure. (See: the unknown group.) Some living individuals have MEMBERS rows after their Statdate, for more information see the section: Interpolation at the Statdate. MEMBERS is most useful when one is interested in an individual's location on a particular date. Simply check MEMBERS for the individual on that date. To find all the individuals in a group on a date, look at all the rows in the table on that date for the group.

MEMBERS is a single population-wide table created and updated automatically. It contains 3 categories of group membership information on each individual: interpolated physical presence in a group; supergroup, i.e. “origin” group, during periods of fission and fusion; and the more broad residency group social membership category.

Interpolation is designed to “smooth out” brief periods of no observation. It guesses which group an individual is likely to be in when there is no observational data. The interpolated group membership information is based on information from the CENSUS, BIOGRAPH, and DEMOG tables and stored in the Grp, Origin, and Interp columns. Interpolation is described fully in a section below. The MEMBERS rows which are the result of guessing have an I as their Origin value.

Census data, and so MEMBERS.Grp, is expected to record group membership at the most fine-grained level. Normally this directly corresponds to membership in the usual, expected, groups but during periods of group fission or fusion the groups censused may not be actual, permanent, groups. Supergroup information locates an individual within their parent group during periods of fission and fusion. This is stored in the Supergroup column.

An individual cannot be interpolated into a group that has ceased to exist, or has not yet begun to exist. The Date of interpolated rows — those whose Origin is I — must be between the Grp's related GROUPS.Start and Cease_To_Exist.

The third category, group residency, is designed to reflect social membership within a group. This as opposed to physical presence. The rules for residency are described in the section on group residency. Residency is based on the GROUPS, BIOGRAPH, CENSUS, and DEMOG tables. Residency results are stored in the Residency, LowFrequency, and GrpOfResidency columns.^[173]

When Residency is R, GrpOfResidency may not be NULL. Otherwise GrpOfResidency must be NULL.

When residency is assigned, the density of data used to make that assignment must also be indicated. GrpOfResidency and LowFrequency must both be NULL (when not resident) or both non-NULL (when resident).

Babase populates this table automatically. For the most part users cannot directly manipulate the table's data, although the data managers must manually trigger residency analysis.

The ranking of individuals within groups. This table contains a row for every month for every ranked individual for every type of rank assigned to the individual. When the ranking has not been done for a type of rank in a month, there are no rows for members of that group for that month with that type of rank.

Rankings are determined via a manual process that considers both quantitative information, such as the outcome of agonism interactions within a particular month, and some qualitative judgments such as other observed behavior during and surrounding the month in question. As such the rankings are somewhat smoothed and are not strictly dependent upon observations made within a single 1 month time interval. For further information please consult your local Babase scientist.

The system will report a warning when a ranking of some Rnktype has been done on a group and there are individuals (returned by the RNKTYPES.Query) who have not been ranked.

Rankings may be based on irregular observations of a group before the long-term study began, or before it became an "official" study group. Either way, the ranks for such a group will likely be before any of the individuals' Entrydates. Because of this, the system will allow but issue a warning when an individual's Rnkdate is before the first of the month of the individual's LatestBirth, and another warning if before that of the Entrydate.

The combination of Sname, Rnkdate, Grp, and Rnktype must be unique.

Ranks are assigned within groups, so all individuals must be in the group ranked at some point during the month. Specifically, MEMBERS must record that the ranked individual is a member of the group as determined by the Grp column, during the ranked month.

Rank assignments should not be interpreted as absolute truth. They are a "best fit" assignment based on the density and volume of available data. Users should remain aware of this and be prepared to make decisions about the accuracy and reliability of individual rows in this table. Three columns are provided to assist users with these decisions: Ags_Density, Ags_Reversals, and Ags_Expected. These columns provide information about the supporting agonism data involving members in this Grp during the month represented by the Rnkdate and who have a RANKS row with this Rnktype.

To fully understand the meaning of these columns, it is helpful to visualize the supporting agonism data in a matrix. Across the top of the matrix, all ranked individuals for a given Grp, Rnkdate, and Rnktype are listed in numerical Rank order (rank #1 is left-most). On the left side of the matrix, the same individuals are listed again in the same order, top to bottom. In each cell of the matrix, there is a number indicating the number of agonisms (from INTERACT_DATA and PARTS) in which the individual on the x axis was submissive to the individual on the y axis. In other words, it is the number of times that the individual on the y axis "won" over the individual on the x axis. See the example matrix below.

-----|-ABC-|-DEF-|-GHI-|-JKL-
-ABC-|-----|--3--|--0--|--2--
-DEF-|--1--|-----|--1--|--1--
-GHI-|--0--|--0--|-----|--5--
-JKL-|--0--|--0--|--0--|-----
            

When data are sparse, a large number of dyads in an agonism matrix will have zero agonisms above the diagonal. When data are dense, relatively few dyads above the diagonal will be zero. The Ags_Density is a proportion that shows the density/sparsity of the related agonism data. In an agonism matrix for all individuals with the same Grp-Rnkdate-Rnktype, the number of dyads in the top half with a nonzero value is divided by the total number of dyads in that matrix's top half. This value is the Ags_Density for all rows with that Grp-Rnkdate-Rnktype. For the rare event that there is only one ranked individual and therefore no dyads, the special value 99 is used instead. With the exception of this one special case, higher values in this column indicate that a larger number of dyads had observed interactions that month, so the rankings are based on a relatively large amount of information. In contrast, lower values indicate that a smaller number of dyads had observed interactions, so the rankings are based on less information.

It is possible to "win" over an individual but still be ranked below them, as shown above. The Ags_Reversals column indicates how many of these so-called "reversals" that the individual experienced. That is, the number of this individual's agonisms — both wins and losses — that are below the diagonal on the matrix for this Grp-Rnkdate-Rnktype. The Ags_Expected column shows the opposite: the number of this individual's agonisms — both wins and losses — that are "expected" because they are above the diagonal. When there is only one ranked individual and thus no dyads, both of these columns' values will be 0.

The Ags_Density, Ags_Reversals, and Ags_Expected values should not be calculated immediately after a row is added, because their values depend on knowing all of the ranks for the Grp-Rnkdate-Rnktype^[176]. Because of this, these columns can be NULL. Their values are calculated by the rebuild_ranks() function, which should be manually executed soon after new RANKS rows are inserted.

The system will return a warning for any row in RANKS with a NULL Ags_Density, Ags_Reversals, or Ags_Expected.

This table records periods (or “bouts”) of time where an individual remained resident in a group. While residency is shown in MEMBERS on a daily basis, in this table those data are condensed into discrete “bouts”: one for each row. This table also includes information showing why each bout started and finished, and how often observation of the individual was designated "low frequency".

A bout of residency is a period of time in which the individual is resident in the same group on every constituent date (every row in MEMBERS). The individual may be present elsewhere during this time, but the group in which they were resident cannot change, as discussed in the Residency Rules. A change in MEMBERS.GrpOfResidency due to a group fission or fusion is not treated as a group change when grouping residency into bouts.

Residencies may begin and end for reasons that are not immediately apparent. To clarify this, these reasons are indicated in the Start_Status and Finish_Status columns.

For each bout, the prevalence of "low frequency" days — MEMBERS rows whose LowFrequency is TRUE is provided. This is shown as a simple count of the number of low frequency days (Days_LowFreq) and as a proportion of all days in the bout (Prop_LowFreq).

The contents of this table are completely dependent on the data in MEMBERS. Data in this table are automatically updated by the system when an individual’s residency data are updated by the rebuild_residency() or rebuild_all_residency() functions. Manual inserts, updates, and deletes can only be performed by an admin.