When you look for holdings for an analyzed volume--i.e., a volume that's part of a cataloged set or series, but that also has its own catalog record--it matters which place you look for the holdings information in the MNCAT public catalog. The "Availability Link" list on the brief display will generally be more complete than the "Availability" line holdings on the full record display. For details, please read the full entry.
I'm learning more about how Aleph works in the process of relinking a number of analytics to their set or serial record, where their item records are stored. One recent discovery is that the holdings listed for an analyzed volume in the "Availability Link" column in the brief MNCAT public catalog display are more complete than the list of holding locations that appear on the full record display. Understanding how Aleph stores and links to item records can help explain this difference.
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.
Now that authority linking has been turned back on, please be aware of a temporary issue regarding the updating of headings with form subdivisions. Specifically, when you update a record with a form subdivision in $$v and the authority still uses $$x for the same form subdivision, Aleph will double the subdivision, e.g.,
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 Aleph checks and finds an authority which matches a bib heading, it replaces the bib heading with the authority heading. This serves to correct minor differences in capitalization, diacritics, punctuation, etc., and is generally a good thing. The problem arises because Aleph's sensitivity to coding variations when checking headings and when updating headings is different. When matching a bib heading to an authority, Aleph normalizes out coding differences (along with minor differences in capitalization, diacritics, punctuation, etc.). When Aleph updates a bib heading, it attends to coding differences; in this case, it sees the authority $$x and the bib $$v as different, and preserves both. This preservation of different subfields is good when the difference is that the bib heading includes subdivisions that aren't in the authority, such as $$e or $$4; but in cases like the one above, it can cause problems.
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.
If the difference involves an initial article, this is an insoluble problem for now, but it may be solved in the future. For more information, read on.
Aleph derives two versions of an access field for browse indexing. One is heavily normalized for rough sorting; the other is more delicately normalized. Aleph uses the latter form to display the heading in the index with punctuation, upper and lower case, etc., which makes the headings more legible. When there are different forms of the delicately normalized heading, Aleph has to decide what to do.
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 index regeneration that has done so much good for MNCAT (authorizing many additional headings, correcting problems from the first index gen for v14, finally making thousands of romanized Arabic, Russian, Indic and Icelandic headings searchable) has also in a few cases gone haywire. Aleph is not sensitive to tag differences; for example, a 400 or 430 reference can match to a 150 heading, resulting in the replacement of the initial subfield(s) of a topical heading with the 100 or 130 data from the mismatched authority. Not good; but fixable.
Some of these bad heading flips were present but undetected in the v14 MNCAT. Others may have newly occured because the updated authority file included new authority records, or because the internal sequence numbers of the authority records changed. Aleph's heading checker essentially accepts the first authority guidance it encounters. Hence, in v16 Aleph may have encountered the wrong authority first, where in v14 it happened to encounter the correct authority first.
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.
The purpose of the on-screen "Correct Display" button, new in Aleph version 16, was a bit obscure to me, but now I think I understand it.
In v14, Aleph was hypersensitive to small differences in the display form of its headings, to the point that minor differences in capitalization or punctuation could split a heading into two entries. In v16, this sensitivity is reduced, which is good on the whole and relieves us of lots of work to merge split headings. But a consequence of this reduction in sensitivity has been a break in the link between the heading form on the record and the display form in the index entry as regards these minor differences. This comes through most clearly when one is correcting a minor discrepancy in a single entry, for example:
"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