FAQ – Adding dates in authority records for personal names
|About PFAN||News and Updates||Rules for Contributions||Name Authority Manual||Participant's Manual||PFAN Policy Statements||PFAN Training||Frequently Asked Questions (FAQ)||Other Documentation||LAC|
LAC recommends that other participating institutions follow the following practices:
- Do not record a full date of birth (year, month, day) for living individuals, nor for people who died less than 20 years ago.
- There are no restrictions for individuals who have been dead for more than 20 years.
- There are no restrictions for individuals about whom information is already publicly available in a source open to the general public (such as Wikipedia, or a printed book).
- It is possible to differentiate living individuals by adding other elements, as indicated in RDA.
Do other participating institutions have to follow LAC's recommendations?
Each institution is free to follow these or not, according to its own internal policies. For institutions choosing to follow LAC's recommended practices, it is also possible to record the full birth date in a person’s authority record, if the cataloguer has received consent from the person. This practice is considered acceptable by LAC, even though it is not part of its initial recommendations.
Revising an existing authorized access point (AAP) creates additional work for bibliographic file maintenance (BFM); therefore, modifying an existing AAP simply to add a birth or death date, when they are absent, is really a last-resort option. Please note that adding a date is allowed in some circumstances (see point 6 below).
When an AAP being established conflicts with another AAP already established in Canadiana for another person, and a date is available for the person already established in Canadiana, but not for the new person, it is therefore preferable to make the new AAP unique by using another method allowed by RDA to distinguish AAPs, such as, (Profession/occupation), (Author of [Title of work]), etc., rather than modifying the existing AAP.
The LAC-BAnQ Policy Statement for RDA 220.127.116.11 states, however: “If there are no additions readily available to differentiate the access point in the new authority record, make an addition to the existing authorized access point”.
When revising existing authority records, the date of birth, if known, must be recorded in field 046 $f, even if not included as part of the access point (see Name authority manual, field 046, 2nd paragraph).
May we add a date to a new Authorized Access Point, being newly created, if there is no conflict?
Yes. The date is a core element when an authority record is created. It must be added, if known, as it helps avoid future conflicts.
Yes. The form of the authorized access point, in Canadiana, does not need to be identical to the form of the authorized access point in the LC/NAF file, since they are two distinct authority files. It may even happen that an authorized access point created by LAC in LC/NAF be different from the access point created for the same entity in Canadiana.
Are there any situations where we may add dates to an existing AAP in a record already in Canadiana?
Adding a birth or death date is always allowed in the following situations:
- When another change has to be made to the AAP (for instance, to fix a typo, update the persons preferred name when the author changes names, or if another name is now more commonly used);
- When a date is already present, to complete an open birth date with a death date, or the reverse;
- When no other addition is available to differentiate an access point in a new authority record. This is a last-resort solution, since it has an impact on BFM.
May we add a date, in $d, to the variant names recorded in field 400, if this information is recorded in field 046 but is not part of the AAP?
Generally speaking, if the AAP includes a date, the variant access points should also include a date. In the same way, if the AAP does not include a date, the variant access points should not include a date, except if a date is required, in the variant, to avoid a conflict between this variant and another AAP.
Last update: 2021-06-01