January 28, 2011

How do authority records define the entities they establish?

In various conversations lately I've been struggling to explain my feeling that authority records contain more than the data they display, and that when they get deconstructed as linked data, this something more needs to be represented in the linked data results. Generally I think of it as an implicit "definition." Some records include more defining information than others, but even those which contain very little are nevertheless asserting the uniqueness of a certain entity--but how can that assertion be explained when the data is minimal and not particularly distinguishing?

The answer is that authorities are embedded in a larger system of information. It is routine to cite a bibliographic source for a name, and early authority control conventions kept the citation minimal on the assumption that the source bib record would also be present in the system and could also be consulted for evidence of the nature and specificity of the entity being established. Thus there was no need to note such useful identifying facts as the publishers and places of publication for a given author's works, since that information was accessible within the larger system. Recent MARC21 authority format changes to support RDA have made places for more of this data in the authority record, but it is important to realize that this penumbra of definitional data found in bib records also belongs to the data set that defines an established entity. As we move authority records into linked data, we need to be sure that data from bibliographic records is also carried along, not simply as information about a given manifestation, but also as information about the manifestation's authors, editors, etc. This is by no means a new idea--OCLC has long been in the business of building augmented versions of LCNAF authorities to enable more sophisticated algorithmic matching between bib records and authorities and more recently between authorities from different authority files in the VIAF. But people new to working with authority records need to be aware of the way many authorities depend on information found only in bib records which contain the authorized heading to define fully the entity they establish.

Posted by s-hear at 12:26 PM

May 2, 2006

How should I cite a name which is used on older LC bib records, but not established?

Older forms found on LC bib records raise a number of questions. Click "Continue reading ..." below for an extended discussion which covers a number of them.

For 670s generally, you cite the source you saw. When a 670 cites "LC manual cat.", it means that someone at LC actually looked in their old card catalog. If you found information by looking in the online LC catalog (which I did for the example used here), that can be reported as follows:

670 LC database, May 2, 2006 $b (hdg.: Fisher, Warren Samuel, 1878- ; usage: W.S. Fisher)

Note that we're citing all the information we found in the file related to the heading, not just a single record. (Source for this in Cataloger's Desktop: Descriptive Cataloging Manual: Public Sections/Z1. Name and Series Authority Records/Variable Data Fields/670 Source Data Found/Special types of citations/LC database.)

The first 670 in an authority record should be for the work being cataloged. In this example, that work shows "Warren S. Fisher." That usage form combined with the additional information found in the LC database and constructed according to AACR2 gives the heading form

100 1 Fisher, Warren S. $q (Warren Samuel), $d b. 1878

The usage information in the 670 above would justify an added 400:

400 1 Fisher, W. S.$$q(Warren Samuel),$$db. 1878

LC would not make a reference for the unestablished "old catalog" heading "Fisher, Warren Samuel, 1878-", since it's not constructed according to AACR2 rules. It would only be added as a pre-AACR2 reference with "$$w nna" if it had been established with an online authority record in that form. If we submit an authority for Fisher through NACO, it will omit the "Fisher, Warren Samuel, 1878-" form. I know that doesn't make practical sense, since this is the form most likely to be encountered on older catalog records; but that's the rule we work under. Once the bib headings are updated in MNCAT, our need for the pre-AACR2 reference will drop off, too.

Even if you have a source where the author appears as "Warren Samuel Fisher," LC would be disinclined to add a 400 for "Fisher, Warren Samuel, b. 1878", since the rule is to disregard differences past the first forename except in unusual cases when making references; so this reference would be considered--well, not exactly the same as, but insufficiently different from "100 Fisher, Warren S. (Warren Samuel), b. 1878".

Posted by s-hear at 12:10 PM

February 2, 2006

Adding death dates

The full entry below includes the announcement from LC's Cataloging Policy and Support Office of how LC will implement the new policy regarding adding death dates to personal name headings with open birth dates, and how we will be implementing the policy locally.

Please note two things in the LC announcement below:

1. There are pieces of the process for managing these updates (an RSS feed from OCLC, the list of 300 headings that LC will be doing) that are not yet in place. NACO participants, please refrain from making these death date additions until these pieces appear.

2. LC is limiting this practice in general to cases where a personal name heading already has an open birth date; and that at LC, except for a list of "300 prominent persons" to be posted soon as a special LC project, the practice will be limited to names that come up on current cataloging or conflict resolution. Through our participation in NACO we will be able locally to add death dates to LC/NACO Authority File (LNAF) headings; but I would encourage NACO participants to be similarly conservative in their approach to this until the volume and impact of these changes in the LNAF is clearer.

As these changes occur, Database Management will endeavor to update the authorities in UMN10 and on the corresponding bib records. We still do not have a means of automatically loading or overlaying new or updated individual authorities from LC, and have not yet implemented routine batch updating of the authority records in UMN10. For now, staff should feel free to edit the date fields in personal name authority records when they find that the LNAF record at http://authorities.loc.gov has been updated, or to report such cases to Database Management, where we will also be working to keep up with the changes as they are reported on the OCLC RSS feed.

If you have questions about implementing this revised practice, please let me know. I'll be posting a version of this message to the "Control Freak" authorities blog available via the Communications/Blogs & Mailing Lists link on the Tech Services home page.

Stephen

Date: Wed, 1 Feb 2006 16:09:27 -0500
From: CPSO
Subject: [PCCLIST] LC Policy statement on LCRI 22.17 and BFM reminder

The LCRI 2005 Update, no. 3-4 is now available on Cataloger's Desktop. Included in this update is revised LCRI 22.17, that now contains an option for catalogers to add death dates to personal name headings with open dates. Although NACO institutions may apply the option (or not) in the manner that best utilizes their cataloging resources, the following information on how the Library of Congress will implement the policy change is provided for your information:

1. In order to begin application of this policy in a manner that minimizes the impact on LC's catalog (and the ripple effect on catalogs worldwide) and maximizes the efficient use of cataloging resources LC's policy on addition of death dates will be the following:

Unless working on *authorized special projects, LC catalogers are asked to apply the option to add death dates to existing personal name authority records with open dates only when a personal name heading is being used on bibliographic records currently being cataloged and/or in the course of routine authority file maintenance (e.g., resolving conflicts between different persons).

Once the impact of this change is fully understood, a more liberal policy for adding death dates may be announced in the future.

2. Please be reminded that dates (either birth or death dates) should not be added to personal name headings on existing authority records that currently do not have any dates, except in cases of conflict, according to current policy.

3. If a name authority record is being established for the first time, birth and death dates may be added to the heading, even if a personal name heading without dates for the same person exists on bibliographic records in LC's catalog.

Bibliographic File Maintenance for NACO Libraries

As long as the only change to the heading is the addition of a death date, NACO libraries are not required to report these changes to LC. In response to a request from LC, OCLC has agreed to provide an RSS feed that will serve as an alert service for authority records to which death dates have been added. LC and the PCC are grateful to OCLC for providing this service that will greatly assist libraries in the maintenance of their catalogs-- an announcement regarding the details of the service will be forthcoming from OCLC.

Note that if the heading warrants other changes (besides the addition of a death date), and is thus no longer a one-for-one change, then BFM should be reported to the coop liaison as usual (cf. BFM FAQ at: http://www.loc.gov/catdir/pcc/naco/bfmguide.html This BFM FAQ and other relevant FAQs will be updated to include information in regard to the addition of death dates.

Catalogers are reminded that when making a change to a date in a 1XX all references must reflect the change and all related NARs must also be changed, e.g., name/title NARs, and BFM reported if appropriate.

* CPSO will shortly be announcing a special project to add death dates to the headings of about 300 prominent persons. To minimize duplication of effort, the announcement will include the names of the persons involved.

Questions, comments, etc. should be sent to cpso@loc.gov

Posted by s-hear at 11:46 AM