Group Membership and Life Events

DAD_DATA (Paternity analysis results)

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.

Tip

Use the Completeness column when planning a new paternity analysis to help determine which paternities should be re-analyzed and which can be omitted from any further analyses.

Dadid (Dad_Data Identifier)

A unique integer which identifies the DAD_DATA row.

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

Kid

The individual on which the paternity analysis was done. A three-letter code which uniquely identifies an individual (an Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here. This column must not be NULL.

Mom_sampled (Mother's genetic sample taken)

TRUE when there is a genetic sample of the mother on file, FALSE when there is not. This column must not be NULL.

Dad_sampled (Father's genetic sample taken)

TRUE when there is a genetic sample of the father on file (the Dad_consensus), FALSE when there is not. This column must not be NULL.

Dad_excl (Dad manually chosen based on an Exclusion analysis of genetic loci)

The father chosen based on an exclusion analysis of locus matches between the offspring and all potential fathers for which genetic data were available (note that potential fathers are by definition fathers that were in the group in which the infant was conceived during the 5 days prior to the Zdate). A three-letter code which uniquely identifies an individual (an Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here. Field observations of physical proximity, social interaction, etc., are not part of this analysis.

This column may be NULL when the exclusion analysis yields no father.

Loci_excl (Number of Loci that do not match the Dad_excl)

The number of loci at which the offspring and father, the Dad_excl, do not match.

The value of this column, when non-NULL, must be between 0 and 40, inclusive.

Pdads_considered (Number of potential dads considered)

Total number of potential dads considered. The primary factors leading to inclusion in the pool of potential fathers are maturity as of the Zdate and membership in the mother's social group during the 5 days prior to the Zdate.[170]

Tip

The POTENTIAL_DADS view may be used to produce a list of potential fathers that are currently considered to be members of the mother's group at the time of conception.

This column must not be NULL and must be between 0 and 50, inclusive.

Pdads_typed (Potential Dads Typed)

The number of potential dads, those which Pdads_considered counts, for which there are genetic data.

This column must not be NULL.

Dad_1perr (Dad chosen by software assuming a 1% error)

The father chosen by the analysis software from among potential fathers (those present in the mother's social group during the 5 days prior to the Zdate) under the assumption of a 1% error rate in the determination of the genotype at the loci. A three-letter code which uniquely identifies an individual (an Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here.

This column is NULL when the automated analysis yields no father given an 80% confidence level.

Conf_1perr (Confidence level given a 1% error assumption)

The percent confidence in the Dad_1perr result. Values must be NULL or integers between 0 and 1, inclusive.

Dad_5perr (Dad chosen by software assuming a 5% error)

The father chosen by the analysis software from among potential fathers (those present in the mother's social group during the 5 days prior to the Zdate) under the assumption of a 5% error rate in determining the genotype at the loci. A three-letter code which uniquely identifies an individual (a Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here.

This column is NULL when the automated analysis yields no father given an 80% confidence level.

Conf_5perr (Confidence level given a 5% error assumption)

The percent confidence in the Dad_5perr result. Values must be NULL or integers between 0 and 1, inclusive.

Dad_allmales (Dad chosen by software from All Males in the population)

The father chosen by the analysis software considering all males in the population under the assumption of a 1% error rate in determining the genotype at the loci. A three letter code which uniquely identifies an individual (a Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here.

This column is NULL when the automated analysis yields no father given an 80% confidence level.

Conf_allmales (Confidence level for Dad_allmales)

The percent confidence in the Dad_allmales result. Values must be integers between 0 and 1, inclusive. This column must not be NULL.

Dad_consensus (The manually chosen father-of-choice)

The father chosen taking all factors into account. A three-letter code which uniquely identifies an individual (an Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here.

This column may be NULL if there is no consensus dad.

Software (Software used in paternity analysis)

Code for the software used[171] in the genetic paternity analysis. The legal values of this column are defined by the DAD_SOFTWARE support table.

Date (Date analysis performed)

The date of paternity assignment. This column may not be NULL.

Comments

Comments on or notes regarding the analysis. This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character. This column may be NULL.

Consensus_Mismatch (Mismatch Types Observed With Consensus Dad)

The DAD_DATA_MISMATCHES.Mismatch category for the trio of Kid, mom, and Dad_consensus.

Completeness (Completeness of Genotypes Used for this Assignment)

The DAD_DATA_COMPLETENESS.Completeness of the paternity assignment (or lack thereof) for the offspring.

This column may not be NULL.

Sys_Period

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

MEMBERS (Day-by-day Group Membership)

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.

Note

Babase requires that an animal be located in exactly one group on any particular day, the combination of Sname and Date should be unique. The intent of this table is to record the location of each animal at the start of each day. See other documents for further information on how the actual practice of data acquisition and entry impacts this goal.

Tip

If your analysis involves group membership and the time period in which you are interested includes a group fission or fusion you may want to be using the Supergroup column rather than the Grp column. An individual's Supergroup does not change until the date fission/fusion completes, whereas Grp fluctuates between daughter/parent groups during periods of fission/fusion. Using Supergroup allows analysis to treat fission/fusion as an instantaneous event rather than one which occurs over time.

The Delayed_Supergroup column is primarily for the system's internal use and can be safely ignored.

Caution

The Supergroup column (and the Delayed_Supergroup column) are not computed automatically. When the CENSUS or DEMOG tables are changed a Data Manager must tell the system to recompute the Supergroup.

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.

Caution

The system enforces this rule "on-commit". In a transaction ending with a ROLLBACK, any changes to this table will not be validated against this rule. This means it is possible for an invalid change to appear error-free if executed in a rolled-back transaction. Committed transactions (and commands executed outside of transactions) perform this check as expected[172].

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.

Note

Social group residency may differ from physical group residency -- the GrpOfResidency value may differ from the Grp value. This is particularly true of males who visit other groups.

Caution

Social group residency is not computed automatically. When the CENSUS or DEMOG tables are changed a Data Manager must tell the system to recompute the social group membership.

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.

Membid (Members IDentifier)

A unique integer which identifies the MEMBERS row.

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

The individual whose location is being recorded. The three-letter code that identifies the individual's row in the BIOGRAPH table. There will always be a row in BIOGRAPH for the individual identified here.

This column may not be NULL.

Date

The date.

This column may not be NULL.

Grp

The group where the individual is located. This is a Gid value from GROUPS. This field should contain the most specific sub-grouping available -- subject to the constraints of the data entry protocol, of course. Aggregation into larger groupings is accomplished by way of the Supergroup column.

This column may not be NULL.

Note

Usage exception: The group recorded for the sub-groups of Alto's group do not necessarily reflect the actual groupings of the animals on a particular day. See: CENSUS.Grp

Origin

A one letter code indicating the source of the location information. This information is derived from, and has the same values as, the Status column of CENSUS, with the exceptions that MEMBERS.Origin contains the I (interpolated) value not found in CENSUS, and does not contain the A (absent) value. The codes are as follows: C (CENSUS) values represent census data points, I (interpolated) values are derived from the census data points, D (demography) values represent demography notes not present in the census sheets, M and N (manual) values represent census data points due to operator intervention in CENSUS . The S, E, F, B, G, T, L, and R codes are derived from analysis of historical data. See the CENSUS section for further information.

This column may not be NULL.

Interp

The time interval, in days, from the date in which an individual was previously observed to be in a group (censused or born into group -- automatic placement in the unknown group does not count) to the date of the MEMBERS row. So the value is 0 on those days on which the individuals are censused (and on the individuals' birth dates), 1 on those (non-census) days immediately before or after the census days, etc. For those MEMBERS rows in which the interpolation procedure has associated an individual with the unknown group, for lack of a better place to put them, the Interp column is the number of days distant from the interpolating CENSUS row, or the birth date, that determined the group membership. Note that the CENSUS row that determined that the MEMBERS.Grp should be unknown may record an absence.

Important

The Interp value is not meaningful over intervals that contain census rows that are themselves the result of an analysis. Over these intervals Interp is NULL. For more information see Interpolation, Data are not Re-Analyzed.

This column many be NULL.

Supergroup

The Gid of the permanent group[174] in which the individual is a member on the given MEMBERS.Date.

Between a group's GROUPS.Permanent date and it's GROUPS.Cease_To_Exist date, inclusive, individuals within the group have a Supergroup value of the group itself.

During fission the supergroup of a fission product on a given date is the parent group, i.e., the GROUPS.From_group.

During fusion the supergroup of a fusion product on a given date is the parent group in which the individual was most recently censused. I.e. one of the GROUPS with a To_group value of the daughter group's Gid, which is also permanent on the given date, i.e. which has a GROUPS.Permanent value on or before the given date and a GROUPS.Cease_To_Exist value on or after the given date, in which the individual was most recently censused. It is an error if no parent group is permanent.

If there is no parent group the group is its own supergroup.

This column may be NULL when the supergroup has not yet been computed.

Delayed_Supergroup

The supergroup, calculated with a delay of 29 days.

This column is used internally by Babase.

This column may be NULL when delayed supergroup has not yet been computed.

Residency (Social Group Residency Status)

Whether or not the individual is resident in the group on the given day. The legal values for this column are:

MEMBERS.Residency Values
Code Description
R Resident -- in the GrpOfResidency group
N Non-Resident -- physically in a study group
U Unknown -- physically in a non-study group

The difference between N and U is whether or not the individual is censused, or interpolated, in a study or a non-study group on the Date in question.

This column is NULL when the row's residency has not yet been computed.

LowFrequency

A boolean. When TRUE the residency status is based upon low-frequency CENSUS data. An individual has low-frequency CENSUS data on a given day if in the last 29 days, including the current day, the individual has 3 days, or fewer, on which census information is recorded -- days for which the individual has rows in CENSUS. The censuses can record absence or presence.[175] Being interpolated does not count.

If the above criteria are not met the LowFrequency value is FALSE.

Caution

CENSUS.Status codes other than C, D, M, and A can often be repeated continuously over periods of many consecutive days. This can distort the low frequency determination.

This column may be NULL when residency has not yet been computed.

GrpOfResidency (Social Group)

The social group in which the individual belongs. This is a Gid value from GROUPS.

This column is NULL when residency has not yet been computed as well as when residency is not established.

Sys_Period

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

RANKS (Rankings Within Groups)

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.

Caution

Be careful when changing group membership or group rankings; the rank will almost certainly change if an individual's group is changed.

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.

Example 4.1. An Agonism Matrix

For a given Grp and specific Rnkdate and Rnktype, suppose that there are only four individuals named ABC, DEF, GHI, and JKL, ranked in that order. A matrix of the agonisms between these individuals in the relevant time period might look like this:

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

As shown here, ABC "won" over DEF 3 times, while in the same period DEF "won" over ABC only once. JKL "won" over no one and "lost" twice to ABC, once to DEF, and five times to GHI. The top-left-to-lower-right diagonal is empty, because it is doesn't make sense to "win" against oneself.

Ideally, when the hierarchy is completely linear, the matrix for this Grp-Rnkdate-Rnktype will have 1) only nonzero values above the diagonal, and 2) only zeroes below the diagonal. When this is not possible, the number of agonisms for each dyad above the diagonal will generally be greater than or equal to that dyad's value below the diagonal. For example, DEF will not typically be ranked above ABC because if so, the number of agonisms above the diagonal (1) would be higher than the number of agonisms below it (3).

For more details about how ranks are assigned, see the data management protocols on the Data Management page of the Babase Wiki.


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.

Note

Historically, the average Ags_Density for all baboon project ranks is roughly 0.3. While the theoretical maximum Ags_Density value is 1, in reality this occurs very rarely and only in small groups. It is especially difficult to attain high Ags_Density values in larger groups, because there are more dyads needing data.

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.

Note

The Ags_Density is a proportion of the number of dyads, while the Ags_Reversals and Ags_Expected are sums of the number of agonisms.

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.

Tip

You may want to use the PROPORTIONAL_RANKS view instead of this table. It includes all of the same columns as this table, but also calculates the ranked individual's "proportional" rank.

Rnkid (Ranks IDentifier)

A unique integer which identifies the RANKS row.

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

Sname

The individual whose rank is being recorded. The three-letter code which uniquely identifies an individual (in Sname) in BIOGRAPH. There must always be a row in BIOGRAPH for the individual identified here. This column must not be NULL.

Rnkdate

A date that falls on the first day of a month, representing The year and month of the ranking. The year must be between 1940 and 2040, inclusive. This column must not be NULL.

Tip

Use the rnkdate() function to obtain the first day of the month when writing queries.

Grp

The group (GROUPS.Gid) in which the individual is ranked.

Rnktype

The kind of rank assigned to the individual, a Rnktype value from the RNKTYPES table. This column may not be NULL. Examples of various rankings are: Adult Females, All Females, etc., as defined in the RNKTYPES table.

Rank

This is the ranking among all the animals of the Rnktype in the group over the Rnkdate period. The most dominant individual is given a rank of 1, the next most dominant a rank of 2, etc. This information is updated through the ranking program and as a rule need not be manually updated. This column must not be NULL. The rank values must be contiguous and start with 1.[177]

Ags_Density

For this Grp-Rnkdate-Rnktype, the number of dyads with observed agonisms in the "expected" direction divided by the number of possible dyads with agonisms in the "expected" direction.

This column may be NULL, but only while awaiting the insert of all rows from this Grp-Rnkdate-Rnktype.

Caution

When using data from this column, remember that the value 99 is used for the rare case where there is only one ranked individual for this Grp-Rnkdate-Rnktype[178] and therefore no dyads. You should not use these 99's as actual Ags_Density values.

Ags_Reversals

For this Grp-Rnkdate-Rnktype, the number of agonisms that this individual experienced that were "reversals".

This column may be NULL, but only while awaiting the insert of all rows from this Grp-Rnkdate-Rnktype.

Ags_Expected

For this Grp-Rnkdate-Rnktype, the number of agonisms that this individual experienced that were in the "expected" direction.

This column may be NULL, but only while awaiting the insert of all rows from this Grp-Rnkdate-Rnktype.

Sys_Period

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



[170] Group membership on the Zdate does not include a male in the set of potential fathers.

[171] Or other basis of analysis.

[172] Ideally, the interpolation algorithim would be written to ensure that individuals cannot be interpolated into groups that did not exist on the indicated Date. If this were so, a separate check in MEMBERS wouldn't be needed. However, this modification to the code is more complicated than one might expect. For various practical reasons, it's ideal to enforce this "group must exist on this date" rule "on commit" of an SQL transaction. In constrast, the interpolation algorithim operates independently of transactions (it was written before the technology to enforce anything "on commit" existed in PostgreSQL). Effectively incorporating this validation of the Date into interpolation will require rewriting interpolation to work in transactions. This will likely be a substantial rewrite, so for now, interpolation and Date validation are performed separately.

[173] To be perfectly clear, the residency status (MEMBERS.Residency) is that of the social group (MEMBERS.GrpOfResidency).

[174] As determined by GROUPS.Permanent.

[175] But an absence and a presence recorded on the same day count only as a single day of censusing.

[176] For example, when the row for an individual at rank 1 is inserted, the Ags_Density, Ags_Reversals, and Ags_Expected can't yet be calculated accurately because the rows for individuals ranked 2 and onward have not yet been added.

[177] Note that the requirement that ranks be contiguous means that in order to change an existing ranking the ranks must first be deleted, from highest numbered rank to lowest, and then the new ranking re-created, from lowest numbered rank to highest.

[178] ...which only happens with adult male ranks.


Page generated: 2022-09-15T15:33:30-04:00.