We don't need to retain these, but neither can we eliminate all the bib 852s, since the local ones are necessary. From time to time Database Management has had a student working at deleting the bib 852s for non-local institution codes, but that takes a certain familiarity with our local codes; and since the public call number indexes are not prone to displaying these, it's a low priority problem.

They really only appear in the Shelflist indexes, where Aleph includes the 852 $b $c in the index string. If the search you do in a shelflist index begins with a local sublibrary/collection code combination (e.g., twils gen ...), these old RLIN codes aren't a problem. They only appear when you look past the numbers beginning with local loc codes. Again, that makes these lower priority for maintenance. Still, it's annoying to see these pop up, and eventually we'd like to get rid of them.

NACO normalization is primarily a set of rules for normalizing MARC encoded name and title headings. This means that NACO normalization goes beyond the rules listed above to include some more specialized rules needed for its particular task. For example, the first comma in a personal name heading usually marks a distinction between surname and forename, and NACO normalization retains it. A name heading in inverted form with a comma and in direct order form without a comma are not considered to be the same, e.g., "Chandra, Prakash" and "Chandra Prakāsh" are both valid NACO headings, and the first comma rule allows them to be distinguished after normalization.

MARC headings are divided into subfields. In name headings, there are cases where the same data element can be found coded with different subfield values, one current and the other obsolete. NACO normalization deals with this by removing the subfield value, but leaving the subfield position marked; i.e., $a $b and $c get normalized to $-, $-, and $-. This means that insignificant or erroneous differences in subfield code values do not affect comparison and sorting, so "$a Microbiology Conference $b (1st ...)" and "$a Microbiology Conference $n (1st ...)" can index the same; likewise "$a Smith, John, $d 1953- " and "$a Smith, John, $c 1953- "

However, outside of MARC name and title headings, the NACO normalization rules do not necessarily lead to good results. Subject headings sometimes use the same words to mean different things, with the difference signified by the subfield code used. For example, under current coding practice, "... $x Portraits" and "... $v Portraits" mean different things when they appear in a subject heading string (the former is a work about portraits of a person, while the other is a collection of those portraits). Treating them as identical is not necessarily the best choice--though neither is indexing them separately with no indication of what the difference between them is, but that's a different discussion. Similarly, the first comma in a topical subject string does not mark a valid distinction between to headings; e.g., "Short stories, African" and "Short stories African" would not both be valid, separate headings, and allowing normalization to treat them as identical prevents an inadvertantly omitted comma from disrupting filing order.

There are also kinds of normalization which NACO normalization does not include, but which have proven very useful. NACO normalization makes no changes to numbers, but there are standardized changes that can be made to numbers in specified subfields that will enable them to file in a numeric rather than a decimal order (i.e., 3, 21, 111 instead of 111, 21, 3). This type of normalization may be judged appropriate, despite not being part of NACO normalization.

More details about NACO normalization can be found at http://www.loc.gov/catdir/pcc/naco/normrule.html .

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".

In Aleph, the bibliographic record is linked to other records, including the holdings record and the ADM or "administrative" record. The holdings record gives information about a location where a copy of the title is held and summary information about what parts of a set or serial are held. The ADM record is the record to which all the item records for the title are attached. An item record can also be linked to a particular holdings record. When such a link is in place, Aleph is able to display holdings just for that location when asked to do so in the public catalog. Still, all the items for all locations are tied primarily to the ADM record. Lastly, an analytic bib can be linked via a LKR ("linker") field to an item on a set/serial record. Each piece can have only one item record. Aleph's ability to link two bib records to the same item has given us linking options we never had in our old NOTIS system.

When an analyzed volume's bib record is linked to the corresponding item record tied to the corresponding set or serial record, the item information can be displayed in the public catalog when the analytic record is viewed. There must be a match between the analytic record's holdings record's sublibrary/collection codes and the codes on one of the set/serial record's holdings records; but once that match on sublibrary/location is made, all the items linked to the set/serial ADM record which match the analytic LKR field's enumeration data will be displayed in the brief display's "Availability Link" column. Each item carries sublibrary location data which it borrows from the holdings record to which it's linked, but every item tied to the ADM whose enumeration values match the LKR field will be displayed; so effectively, items in several locations can appear in the "Availability Link" column even though the analytic bib record has a holdings record for only one of the locations.

By contrast, when the full bib record is displayed in the OPAC, it shows data only from the holdings records linked to it in the line labeled "Availability." If only one location has a holdings record, only that location will show in the full display, and only its items can be called up by clicking the link. Since many analytic records were originally created for a specific collection, many do not have holdings records for all other copies in the system.

So, for the most complete listing of copies held, check the Availability Link column on the brief display. There can still be other circumstances (e.g., differing Enum values on the items) which will cause one or more location's copies not to display here; but the absence a holdings record tied to the analytic bib record will not be one of them.

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

�Noble gases� is just an arguable label. The category is consistent and coherent. The fact that it�s been arguably labeled doesn�t call the success of the categorization/classification into question.

Classification places single items for retrieval. It also places related items together. Shirky seems to acknowledge only the former function, and to ignore the latter.

Before making assertions about how Yahoo views its users and how Yahoo perceives reality, it might be good to know more about what constraints their data storage and retrieval software impose on their definitions of categories and assignment of items to them. The decision to assign categories to a single rather than multiple hierarchies may be a software constraint, not a philosophical position.

The assignment of an object to multiple categories is really managed by subject headings, not the addition of secondary classifications. Are we going to get to LCSH? Apparently not.

Google search does not categorize at all. It just retrieves on user-specified terms. It sorts the results, but the sorting is not categorical. On the other hand, Google�s Directory is classificatory, and works a lot like Yahoo. (Oh, but fewer people use it, so it must not have any value.)

Decisions about how to build brief representations of objects (i.e., catalog records) because the full content is inaccessible to machine manipulation are different in kind from the decisions made possible when using computers to analyze fully machine readable documents for retrieval. It�s like comparing the physical skills needed for professional football to those needed for PlayStation football.

Search vs. categorization is a false dichotomy. Presuming that a user preference for search over the categories in a majority of cases proves categories have no use and are not desirable is a false leap of judgment. If categorization is a bad idea, why does anyone use Yahoo?

The characteristics suggested for domains amenable to classification lean too heavily on one example, and misjudge the value of bringing like but not identical things together within a browsable frame. It also misplaces the unit with which ontology is concerned�i.e., not the elemental components, but the categories within which they fall. It�s the logic of ideational collectives into which the elements fall that determines whether classification is useful, not the distinctions between the base level units being organized.

The point made about the loss of nuanced semantics when a preferred term is selected from several candidates is valid, to a point. But it overreaches in implying that the differences between terms mean that there is no relationship of interest between them. Someone looking for a conversation with like-minded others might appreciate the distinctions in LiveJournal, but someone researching the range of opinions on a topic would find the data gathering task under this system significantly more laborious.

The notion that classification/categorization is a one-time-for-all activity is false. LCC adds new class numbers, LCSH adds new terms and revises old ones, DDC has its phoenix schedules. The fact that these systems are dynamic rather than static does mean that they require more work than the na�ve might assume, but it does not disprove their utility. (And �Former Soviet Union� is primarily a label for a part of the world. If a better label were found, no massive reshelving at LC would be required to implement it. Alternatively, if Shirky is suggesting that some other organization and sequencing of materials about the places in the former Soviet Union would be superior, is he not engaging in the dreaded �fortune telling� himself?)

URLs are also volatile, and can point to things that require payment or authentication to access. For both of these reasons, user categorizing of links can be a wasted effort of no use to other users.

Many words, even words in natural language, contain an element of classification. The fact that one can derive sets of similar objects from users� natural language terminology does not mean that no classification has been employed. It just means that the underlying classificatory functions of words have been invoked to derive a set of transpersonal categorizations.

The selectivity of tagged links in del.icio.us gets scant attention. Given that it only includes URLs that someone has chosen to preserve, is it really a strategy for tagging all URLs? If it were to be extended that way, would it still be as useful?

It�s also interesting that no comparison is made between del.icio.us�s tagging of URLs by users of web pages vs the metadata tagging of URL-addressed pages by their creators. Part of the utility of del.icio.us may derive from its aggregation of reviewers� rather than creators� tags.

Shirky also slights the role of language as a structured system that stands between individuals and the objects they describe. The rules and conventions of language both enable and constrain both freedom and consensus in the use of terms. Formal classificatory systems draw on the ability of language to represent logical relationships for shared understanding and use. The informal ones that Shirky is advocating do the same, but with a lot less discipline and a higher risk of tagged items being �unfindable� because of idiosyncratic use of terms, or being findable only through a laborious series of searches for multiple terms.

For all the disagreement expressed above, I fully agree with Shirky�s point that informal user-driven building of access paths and terminology is the only viable approach to making the bulk of web objects accessible. I also agree that the consistencies and relationships that emerge when vast amounts of informally generated tagging data are aggregated have great utility. I just don�t think that the alternative methodologies he disparages or their appropriate applications have been treated fairly, or even well understood. I also find the notion that classification is a kind of arrogant assault on freedom to be tiresome. Formal classification is a game with rules. Playing the game means accepting the rules, and thereby getting the benefits of a more disciplined approach to organizing information. Shirky�s boast that end users can apply terminology �without having to agree with anyone else about how something �should� be tagged� is analogous to arguing that the umpire has no right to insist on the number of bases that �should� be tagged before heading for home plate. It�s the attitude behind that sneering �should� that grates.

OCLC does not load all records immediately. OCLC's matching algorithm is fairly complex, looking for multiple points of consistency. When such things as title, year of publication, ISBN/ISSN, publisher, and system number all match up, OCLC promptly and reliably adds our holdings symbol to their WorldCat record. However, if there are discrepancies, or if the record is new to OCLC, it is shunted off for manual review, which can be very slow. Consequently, original University of Minnesota records (e.g., for theses) are often not found in WorldCat, or may be long delayed before finally appearing there. Also, OCLC does not routinely remove our holdings symbol when we include "deleted" records in the batches we send, so many of the titles we appear in WorldCat to hold have actually been withdrawn or lost, as indicated in MNCAT.

Prior to our move to Aleph, RLIN was a more accurate mirror of MNCAT, because RLIN maintains a copy of each RLG member institution's record. While in NOTIS, we would routinely batch update our bibliographic records in RLIN whenever changes were made to the bib record in MNCAT. Since moving to Aleph, we have limited RLIN updates to cases where the MNCAT holdings record has been added or modified; so heading corrections no longer prompt an update of the RLIN copy of our record. Still, RLIN and Eureka are currently a closer reflection of MNCAT than WorldCat.

MNCAT is our library of record. MNCAT should be consulted to find out what we hold, and where it is shelved. When WorldCat indicates that we have a record but MNCAT does not, WorldCat is wrong in the vast majority of cases; and many of the titles we do hold do not and may never appear in WorldCat.

Authority: Children $$x Prayer-books and devotions.
Bibl hdg.: Children $$v Prayer-books and devotions.
Upd bibl.: Children $$x Prayer-books and devotions $$v Prayer-books and devotions.

The simplest solution is to follow the authorized form and use $$x. Eventually, these will be corrected to $$v; and in the meantime, $$v and $$x will interfile happily, so the coding difference will be invisible to users. For a more detailed explanation of the issue, read on.

When Database Management and LEO staff were working through these issues in order to get flipped headings from the V14 to V16 conversion fixed and get automatic updating from authorities turned back on, we determined that in most cases, the doubling of form subdivisions was due to the presence of an updated authority containing $$v and older bib headings containing $$x. Most of our bib form subdivisions are still in $$x. To solve the doubling in these cases, LEO ran a job which identified all the authorities containing $$v and set the UPD=N flag in them. This means that Aleph will not update a bib record which appears to match one of these authorities, and will not mistakenly create doubled form subdivisions.

The other side of this coin is the authorities which still contain form subdivisions coded $$x. LC is gradually working through its authority files creating form subdivision authority records (using tag 185) and revising heading authority records which contain a form subdivision. Our authority file contains a mix of these updated and non-updated authorities. As LC completes its work and as we resume our batch updating of authorities with newer versions from LC, these instances of authorized headings using $$x for form subdivisions will go away. For now, though, we're in an interim phase. (NB: These authorities are exceptions. LC does not routinely create authorities for headings ending in form subdivisions, but it does do so when such a heading has been used as an example or a reference on another authority.)

One good thing about the indexing in Aleph version 16 is that it is NOT sensitive to nearly as many minor differences in headings as version 14 was. In version 14, minor differences in capitalization, diacritics, punctuation, etc., and in coding, would cause separate lines (i.e., split files) to appear in the index. Version 16 is much better at recognizing that such differences still belong to the "same" heading, and is able to represent them with a single merged index entry. Therefore, the urgency of standardizing the coding of form subfields has considerably lessened with version 16

So, back to solutions: the simplest correction is to follow the coding in the authority, even when it is obsolete. Doing so will avoid the subdivision doubling, and will not cause problems in the index. The more involved solution is to revise the coding in the authority to $$v, and add the UPD=N field to avoid causing doubling of older bib headings containing $$x form subdivisions. Database Management will revise any authorities like this that we find or have reported to us during this interim phase. This will allow use of the current $$v coding in the bib record. The long term solution will be to replace these authorities with updates from LC. Our batch updating process will include a step to set such authorities to UPD=N as we load them. Eventually we may update all the older $$x bib form subdivisions to $$v, but that is not a high priority given that they are no longer causing split files.

In any case, it is always a good idea to glance over a bib record after sending it to the server. In most cases any automatic heading updates will be good changes; in some cases, the updated record may reveal a case where an incorrectly coded subdivision (e.g., a place name in $$x rather than $$z) caused the kind of doubling that's been described, and should be corrected; and in some cases, there may be a doubling of something that was correctly coded in the bib record but incorrectly coded in the authority, and therefore has doubled.

If you have any questions about this, please let me know.

In version 14, Aleph usually decided that it had separate entries. This meant that a host of small differences--capitalization, punctuation, spacing--could cause what should be a single index entry to split into two or more entries. Version 16 improves on this significantly--Aleph is now able to accept that these kinds of differences are ignorable, and to display only one of them as representing all. But, in the case of initial articles, Aleph is still unable to see the two entries as the "same." If we could eliminate the initial articles from titles in the bib records, that would solve the problem; but that would also violate standard cataloging rules, which call for including the initial article in 245s, but excluding it in $t's and 130 uniform title entries.

What is needed is for Aleph to take the filing indicator into account when constructing the more delicate filing form. If it were able to use the filing indicator to offset the initial article correctly, the entries would merge. Possible downsides: no more non-filing initial articles in the index (some like seeing them there); and the possibility that the form selected for display in the index might be one of the 245 forms, which often (and properly) do not uppercase the first filing word. In any case, these would be smaller problems than the split in the headings we see now. I expect we'll see a fix for this at some point; but there's nothing we can do now. The underlying data is correct.

The problem with formal adherence is that it sidesteps the question of what terms mean. Only the simplest controlled terms lists use terms that are fully and mutually exclusive of one another. In most cases, the relationships between terms are more complex. In LCSH, two main devices are used to provide logical hierarchies of terms. Broad terms are assigned one or more subdivisions to narrow the meaning of a heading. Related terms are linked by cross references in broader/narrower hierarchies, again to specify a range of broad to narrow meanings. The specific meaning and correct application of a term in this kind of system depends on an understanding of the system�s principle of using the most specific terminology appropriate for describing a particular resource, and of how each term relates to the larger list. This could be called semantic adherence. Semantic adherence to a controlled vocabulary goes beyond formal adherence in that it seeks consistency with the meaning of terms as defined in the authorizing source, as well as with their forms.

Semantic adherence is more complicated that formal adherence. The specific meanings of terms are not routinely expressed in the authority records which make up a controlled vocabulary, and are rarely conveyed in a simple list of the terms. They are not typically available to automatic term matching algorithms, and cannot be typically be validated by machine tests. They may not be understood by users of the list who are not informed about the rules and discipline of the community that prepared the list. For all these reasons, it is doubtful that simple formal adherence to a controlled vocabulary will equate with semantic adherence to the same vocabulary.

The question then becomes, how much does the added value of a controlled term depend simply on its form, and how much does it depend on both the term�s form and its semantics? Consider two examples:

The diary of an American Civil War Confederate soldier might be assigned any of the following controlled LCSH headings, all of which are formally valid:
 United States
 United States�History
 United States�History�Civil War, 1861-1865
 United States�History�Civil War, 1861-1865�Personal narratives
 United States�History�Civil War, 1861-1865�Personal narratives, Confederate

A collection of photos of the B-1 bomber might be assigned any of the following controlled LCSH headings, all formally valid:
 Airplanes
 Government aircraft
 Airplanes, Military
 Bombers
 Strategic bombers
 Jet bombers
 Supersonic bombers
 B-1 bomber

In the context of a particular database, any of these levels of specificity might seem more or less appropriate for describing the specified content. However, to be consistent with LCSH semantics and rules of application, only the last and most specific terms would be appropriate. If semantic adherence is not undertaken by the creators of a set of databases, how much of the value of the controlled terms will be preserved for users attempting to search across those databases with the controlled vocabulary?

User satisfaction with searching across databases which share only formal adherence to a particular controlled vocabulary is a question that can only be properly settled by research. However, in principle the value of controlled terms does not reside simply in their �valid� form. It depends also and crucially on their semantics. The added value of authority control thus depends on:
 acknowledgment of an authoritative source for the form and meaning of terms
 discipline in the application of terms
As agencies and database creators seek to expand the utility of controlled vocabularies for users outside their source communities, there is an increased need to assign explicit definitions to authority records and to inform outside users of their rules of application. This need for more explicitly specific semantics in authority records was recognized by Francoise Bourdon in her book International cooperation in the field of authority data (Saur, 1993) in relation to name authority files; it is just as true for subjects, and for other kinds of controlled vocabularies.

Broadly speaking, these changes fall into two types. In some cases, a 4XX reference flips all instances of an unrelated heading to match its 1XX, and there are no correct uses of the 1XX heading in MNCAT. These are relatively easy to fix using either the Correct button or an Aleph batch job. More problematic are cases where the flipped headings get merged into a larger batch of correct MNCAT headings. For example, the LC children's subject authorities simplify some LCSH headings by replacing them with a single heading, which also happens to be an LCSH heading. The LC children's subject authority combines the LCSH headings "Evolution" and "Human evolution" into the single heading "Evolution." Heading flips of this kind can be very hard to untangle.

Fortunately, LEO has been able to run a job comparing the v16 headings with their v14 counterparts and listing all those which were flipped, including each bib record number. This list will be of great aid in identifying which headings need to be corrected, and which bib records were affected in those cases where headings were incorrectly merged. LEO and TS are also working on measures to ensure that these kinds of flips will not continue to be a problem.

So, what should you do? For now, if you encounter an out-or-place heading, please report it to fixit@umn.edu . If you want to understand how things went wrong in more detail and fix a problem yourself, look for an authority record matching the base of the out-of-place heading. Check its 4XX fields--could one of them have matched the base of a more appropriate heading for the bib record? If so, that's the culprit.

Two changes are usually necessary in the authority record before the bib records can be fixed. Call up the problem authority in the Cataloging Record display. Extend the 4XX with some reasonable text (e.g., add a parenthetical qualifier) to get past a mandatory block on updating an authority with a 4XX matching another authority's 1XX; and add a UPD field to block future use of the record for updating, e.g., "UPD __ $$a NO" Once the new update status is reflected in authority link text in the UMN01 index, the bib headings can be safely corrected.

"Biology--Polar Regions" should be "Biology--Polar regions."

There is only one hit for this heading. The Correct Heading button lets me change the bib heading to "regions", but the display form of the heading is not changed--it still shows "Regions." To complete the correction, I use the Correct Display button. It lets me doctor the display text in the index record to the form I want. Having taught Aleph not to regard differences like R/r as significant enough to result in a separate display, we also have to accept that when we make such a change, Aleph will ignore it unless we intervene with the Correct Display button.

So my guess is that we'll use the Correct Display button mainly to tidy up the index after using the Correct Heading button to correct the bib data. If we used only the Correct Display button, the entry would look OK, but the underlying bib data would be uncorrected.

Please note that only a few staff are authorized to use the Correct Heading and Correct Display buttons. If you have corrections which would best be done with these buttons, please report them to fixit@umn.edu

The former category is discussed in detail in a FAQ posted to the NACO web site at:

http://www.loc.gov/catdir/pcc/naco/bfmguide.html

The site offers examples of the kinds of changes that need to be reported (e.g., two authors whose titles have been confused under a single name heading), and those which don't.

The second category involves records outside the scope of the BFM rule. Some are marked with the legend [from old catalog] in LC's browse indexes (at catalog.loc.gov). Other older records when viewed in LC's web catalog as MARC format records show in the 906 field the words "OCLC replacement." The answer to question 4 in the NACO FAQ on older records at:

http://www.loc.gov/catdir/pcc/naco/bfmfaq.html#4

instructs us that neither of these are candidates for BFM because they haven't been distributed by LC. You may find versions of older catalog records in OCLC flagged "D" (i.e., based on LC cataloging), but that's because some other library did copy cataloging from an LC card and correctly put DLC in the 040 $a; they're not actually distributed by LC as MARC21 records.

Of course, there is also an element of frustration in seeing a mistake and being asked not to report it; but that's the rule for now.

Authority records can also express relationships between headings. The authority for the FBI also points to a heading for the body's earlier name: United States. Dept. of Justice. Division of Investigation. The authority record for the topic Ostriches also points to broader and related topics: Birds, Ratites, and Cookery (Ostrich).

Often, authorized headings include more information than anyone would search for. This enables the system to display a clear and distinct heading in response to a partial or truncated search (e.g., "fitzgerald f s" leads to the full name heading above), and to distinguish between two similar entries (e.g., Wagner, Richard, 1813-1883 (for the composer) and Wagner, Richard, 1939-1972 (a dancer and choreographer).

Stephen