Accession numbers should be used for local ID whenever possible. The accession number is a unique number used to identify the specimen in the institution's collection inventory.
If the accession number is unknown enter {UNK}.
House names, band numbers, tattoo numbers, transponder numbers and other types of useful identification, (like three toes on the left hind foot), should be listed in Special Data not as local ID.
Some locations may use more than the six characters allowed for local lD in this case, the correct value should be abbreviated in the <LOCAL ID> field the complete to ID entered in Special Data.
Some private bird breeders use the bird's band number as the accession number. Band number can be entered for the local ID but this should be noted in Special Data.
Local ID is entered or edited by:
(1) selecting Data Entry from the Main Menu of SPARKS
(2) selecting Edit Animal Data from the Data Entry menu
(3) selecting the Event Records window (upper right of Data Entry screen) and pressing enter
(4) selecting an event type (birth, wild-caught, transfer, death, release)
(5) entering the mnemonic for location where the event took place
(6) entering local identification number (local ID) at the event location
67
When entering a transaction, information on ownership of individual specimens is sought in each event type by the question "Is a loan involved?" If no loan is involved, or it is uncertain whether a loan is involved, enter {N}.
If a loan is involved, enter {Y}. SPARKS will then ask two questions: is this a physical event, and is this an ownership events
If the specimen actually moves between institutions on a loan basis then it is a physical event {Y} and not an ownership event {N},
If the specimen physically moves between institutions and changes ownership then it is a physical event {Y} and an ownership event {Y}.
If the specimen does not physically move between institutions but does change ownership then it is not a physical event {N} but it is an ownership event {Y}.
lf a specimen is on loan and gives birth, offspring which belong to the loaning institution should be recorded as a physical event {Y} and an ownership event {N}. An additional transaction should be entered for the loaning institution as a transfer indicating that it is not a physical event {N} but is an ownership event {Y}.
Determination of ownership and communication about events and recommendations for specimens on loan are the responsibility of the participating institutions as determined by (breeding) loan agreements.
OWNERSHIP SHOULD NOT BE
RECORDED IN A STUDBOOK
UNLESS THE MANAGEMENT PLAN
HAS IDENTIFIED IT AS A PRIORITY
68
The function of the transaction date goes far beyond the determination of when a specimen arrives at or leaves an institution. Transaction dates for births, captures, transfers and deaths are essential data for demographic analysis. Demographic analyses are performed by including individual specimens in specific age-classes (individual units of age, usually measured in years). For example, if a specimen is in the captive population from its third to its fourth birthday, it is counted as living during the fourth year age-class. During this period it is at risk to reproduction (measured in the age-specific fertility, M,) and death (measured in the age-specific mortality, Q,), M, and Q, are the variables that constitute a SPARKS life table, the basis for population size projections. If a specimen dies or is transferred oui of the population halfway through the age-class (i.e., at three and a half years of age), it is counted as half a specimen at risk for fecundity during the fourth year age class. Genetic and demographic analyses often use views (see page 26 on views in SPARKS) that include a range of dates. This is why entering transaction dates is very important for population demography, If a transaction date is entered as unknown, SPARKS often cannot assign that portion of a specimen's life to the life table.
Studbook keepers are commonly confronted with date information of low precision: the exact date for an event (transaction) is uncertain. Often the reporting institution can only establish that a specimen arrived or died during a period such as a month or year. For some long lived species, event dates may only be reported to the nearest decade or a broad range of years. SPARKS allows the studbook keeper to enter dates that are less precise than the exact date. There are four different levels of date precision that require different standards for SPARKS data entry.
Exact Dates: The most precise date precision level is obviously the exact date. This is used when the specific date for a transaction is reported to the studbook keeper. The precise date is entered in the <TRANSACTION DATE> field, and there is no entry in the <DATE ESTIMATE> field.
Nearest Unit Estimates: The next level of date precision is an estimate to the nearest unit of time: either day, month, or year. These estimates range in precision from within a few days, during a month, or during a year. When the studbook is printed, only the level of precision is shown (i.e., the month or year of the estimate). This option was included in SPARKS to allow the studbook keeper to establish a degree of precision for date data. Although this is a nice feature for showing precision, it does not affect analyses. When an analysis is performed on the studbook, SPARKS ignores the estimator and treats the date as an exact value. This is a key concept that must be considered whenever
69
date information is entered into SPARKS; the correct way to treat this level of precision is to enter the mean of the range of the date and the appropriate estimator. As an example, if it is known that a specimen arrived at an institution during a specific month, the mean date for that period (a month) is the 16th of the month (for months with 31 days). This is the appropriate date to enter into the <TRANSACTION DATE> field. In the <DATE ESTIMATE> field, an {M} is entered. If a specimen arrived sometime during a calendar year, the mean date for the year {1 July 19__}7 is entered into the <TRANSACTION DATE> field and a {Y} is entered into the <DATE ESTIMATE> field. When the birth date and death date for a specimen are estimated to the same calendar year, the birth date should be entered as splitting the year into thirds: {2 May 19__} and the death date should be entered as {1 September 19__}.
Time Range Estimate: The next lower level of precision is a range, plus or minus a several years. This level of precision denotes that an event took place within a range of years. As an example, if a transfer took place in 1991 or 1992, the mean date for that period, (i.e., {1 January 1992}) would e entered in the in the <TRANSACTION DATE> field and {R1} (indicating a date range of plus or minus one year) in the <DATE ESTIMATE> field. To estimate an event within a decade, the mean date for the decade, {1 January 19_5}, would be entered in the <TRANSACTION DATE> field and {R5} (indicating a date range of plus or minus five years) in the <DATE ESTIMATE> field. SPARKS will use the date entered in the <TRANSACTlON DATE> field for demographic analysis and that this date must be the mean of the range of the date precision.
Unknown Date: The lowest level of precision is an unknown date. Unknown dates are created by entering a {U} in the <DATE ESTIMATE> field. The {U} instructs SPARKS to ignore any date entered into the <TRANSACTION DATE> field during analysis. This removes these specimens from demographic analysis.
The use of date estimations by SPARKS demonstrates the contradiction between the information in a studbook and how that information is used during analyses. As noted above, SPARKS treats estimated dates as exact values. A knowledgeable studbook keeper can improve the precision (and often the accuracy) of the date data by knowing the biology and history of the species. For example, if a species gives birth only during a
7 SPARKS requires that dates be input as either {day/month/year} or {month/day/year}. To avoid confusion between these options, throughout this document, dates will be shown as {1 July 19__}, where the open spaces represent values to be determined by the user (e.g., year).
70
particular season and the studbook keeper knows that a specimen is born during a particular year, the level of precision can often be narrowed to a period of a few months. If a species usually gives birth either during January or February, the studbook keeper could enter {1 February 19__} (the mean date) in the <TRANSACTION DATE> field, and {M} in the <DATE ESTIMATE> field. This would be far more precise in the demographic calculations than entering {1 July 19__} and estimating the birth to the year.
Date estimates should be interpreted as "on any date within the estimated period." Thus, an estimate to calendar-year means that the event could have occurred on any of the 365 days of that year (with equal probability). Great care must be given to avoid overlap between events with estimated dates and events with known dates. These overlaps indicate that dates can be estimated with greater precision. For example, if information is provided that an event (e.g., a birth) can be estimated to a calendar year, but a known event (e.g., a transfer on 12 August) occurred within that same calendar year, then the birth even cannot be estimated to calendar year because it could not have happened (e.g., it could only have happened before or after 12 August). In these situations, the estimate must be adjusted to the midpoint of the uncertain period (e.g., either the midpoint of 1 January to 12 August or 12 August to 31 December in the current example).
The sequence of transactions (events) is sorted by the <TRANSACTION DATE> field. This means that an event with an earlier transaction date will be listed before an event with a later transaction date, This seems logical for a transaction with some known transaction date What happens when the date is unknown? These transactions are automatically given today's date and, are therefore sorted after all other transactions with real dates. For this reason, a transaction with an unknown date requires a date in the <TRANSACTION DATE> field to allow SPARKS to correctly sort transactions in ascending order. For unknown transaction dates, a date that is between the transaction date {or removal date if not blank) of the previous transaction and the transaction date of the next transaction in sequence, As discussed above, this date will be ignored by any analysis performed by SPARKS, but will be used to correctly sort events,
SPARKS allows the studbook keeper to include removal dates for some transactions (in the <REMOVAL DATE> field). This feature increases the precision of the data by including when a specimen leaves an institution and allows specimens to be
71
removed from the captive population without dying. T-here are some potential problems with the use of removal dates that do directly affect analysis. For example, when removal dates differ from subsequent arrival dates (=transfer event dates), events that occur during transit (i.e., death) are omitted from demographic analyses. Thus, it is recommended that, as a general rule, removal dates be left blank in the studbook database.
The most appropriate place for removal dates is in physical transfers of specimens. This allows the date of departure from one institution to be different from the date of arrival at the next institution. Often this reflects reality more clearly than not using a removal date. lt is common for specimens to take several days, weeks, or even longer during transit between institutions. However, there are unforeseen consequences to recording this unassigned time between institutions. During the period between removal date and arrival date (at the next location), SPARKS does not count a specimen in the demographic analysis (specimens that die in transit can be noted in Special Data). Thus, when data are exported for demographic and genetic analyses, some specimens might be omitted from an analysis because they were in transit. For most analyses, specimens in transit within a region should be included in the analyses. Moreover, data entry errors in removal dates can lead to considerable confusion regarding correct location of parents and offspring. Unless an SSP© or population manager has explicit reasons for tracking transit time between institutions, it is recommended that exact nof estimated removal dates not be entered into the studbook.
An important function of the removal date is to establish when a specimen is lost and can no longer be tracked by the studbook keeper. For example, when a specimen enters the private sector or leaves the studbook’s region, it should be entered as lost-to-follow-up. Specimens that have not been reported as dead, but must be dead because of the time span since the last known location, should also be entered as lost-to-follow-up (see page 74 on how to enter lost-to-follow-up).
Death dates should only be estimated with great caution. Estimating death dates requires information that can generally fix the time and location of death. Specimens that have disappeared from an institution and are probably dead, should be listed as lost-to-follow-up. Under no circumstances should a specimen be assumed dead or assigned a death date just to remove it from reports or analyses! Death dates should be estimated to the midpoint of the estimated unit (e.g., {1 July 19__} for an estimate to calendar year)(see above section on date estimates). When the birth date and death date for a specimen are estimated to the same calendar year, the birth date should be entered as splitting the year into thirds: {2 May 19__} and the death date should be
72
entered as {1 September 19__}.
NEVER KILL A SPECIMEN JUST TO
REMOVE IT FROM A REPORT OR
ANALYSIS -
USE LOST-TO-FOLLOW-UP
73
A specimen is considered lost-to-follow-up when the final disposition of the specimen is unknown. Lost-to-follow-up should be used to designate specimens whose fate is uncertain. This includes specimens transferred to institutions that don't report to the studbook keeper, specimens that may have (or probably have) died, and specimens that have just disappeared. Presumptions of deaths may severely bias demographic analyses: lost-to-follow-up removes the specimen from the life table without the presumption of death. Under no circumstances should a death date be assumed or arbitrarily assigned for any specimen.
There are three general situations in which a specimen can become lost-to-follow-up:
(1) Transfer from a known location on a known date to a known location (e.g., out of the region for a regional studbook);
(2) Transfer from a known location on a, known date to an unknown location; and
(3) Disappearance (death or transfer) from a known location on an unknown date (if transfer, to an unknown location).
An example of the first situation is a transfer of a specimen to a location that does not (or historically did not} keep records. Therefore, although it is known when and where the specimen was sent, there is no information about how long the specimen lived there or where the specimen was transferred subsequently. In this situation the specimen should be recorded as lost-to-follow-up the day it was sent to the new location.
The second situation can occur when there is a failure to link a specimen's move between two institutions. To link, the sending and receiving institutions must submit a record to ISIS and/or the studbook keeper. When the link is not made there are two records: one that ends in lost-to-follow-up on the day the specimen was sent and one that starts with unknown birth date, parentage, etc.
The third situation can occur when a specimen is lost within an institution's record system. For example, a specimen remains on the institution's inventory for an extended period after the specimen had actually been transferred or died. Here, the specimen should be recorded as lost-to-follow-up around the last time the specimen was known to
74
have been at the institution.
Lost-to-follow-up can be entered in two ways: as an unknown removal date at the last reported location (i.e., a {0} in the <REMOVAL DATE ESTIMATE> field) or as a {Y} when SPARKS asks if the specimen is lost-to-follow-up. Although these methods are equivalent, it is recommended that lost-to-follow-up be only be entered using the {Y} response; this will avoid potential confusion with the recommendation to leave <REMOVAL DATE> and <REMOVAL DATE ESTIMATE> as blanks.
Lost-to-follow-up indicates that a specimen's whereabouts are unknown from the date of arrival at a reported location. Thus, when a specimen is known to be at a location for a period but then disappears from that institution's records, it becomes lost-to-follow-up at some point after the arrival date at the known institution. One way to deal with this situation is to transfer the specimen to an unknown location on the last date its location was known (often, this date is an estimate! ). However, this implies that the specimen was transferred when it might have died at the known institution. Thus, the best tactic for this situation is to transfer the specimen to the known institution on the last known date (SPARKS permits transfers from a location to that same location). The specimen can then be listed as lost-to-follow-up after the known date
Lost-to-follow-up is entered by:
(1) selecting Data Entry from the Main Menu of SPARKS
(2) selecting Edit Animal Data from the Data Entry menu
(3) selecting the Event Records window (upper right of Data Entry screen)
(4) selecting an event type (birth, wild-caught, transfer, death, release)
(5) entering the mnemonic for location where the event took place
(6) entering local identification number (local ID) at the event location
(7) entering loan as {NO} (unless ownership is tracked)
(8) entering the date of the event (and date estimate if appropriate)
75
(9) entering removal date as blank
(11) entering removal date estimate as {U}
or
(11) entering removal date estimate as blank
(10) entering lost-to-follow-up as (Y}
76