Fixing misuse of 246s; thoughts on ILS shortcomings.

Recently we have been tasked by our Library Director with fixing some past cataloging practices. In the past, our Catalogers helped our Special Collections department with highlighting local special collections in the catalog. I understand why they did what they did, but the method chosen was a flagrant violation of cataloging rules and misuse of MARC coding. Basically the 246 field (alternative title) was selected so that Special collection titles could be inserted here and would appear as an indexed, hyperlink-clickable title heading. It was a functional choice, a cheat, a short-cut. I understand completely why it was done.

In point of fact, the idea of local collections, near as I can tell, as such, falls through the specifications for existing MARC coding. I'm not opposed to the idea of having an clickable field in the OPAC display that is indexed and enables the user to access all the books in a local collection simultaneously in a results list. The problem is twofold. 1) there is no concise, already existing MARC tag that really captures this information; there needs to be. The only solution I see is coding some 901-907 field to capture this info and index it. 2) even if the info is successfully captured in a MARC tag between 901 and 907, the local ILS has to be able to index this information and display it, and this requires systems-level savvy that previously was lacking, which is why I suspect the 246 was opted for originally.

I don't currently know if Voyager is capable of indexing and displaying MARC tags 901 through 907. I would need to investigate this with my Systems Librarian. Our interim solution has been to code the "local collection" details in the 590 local note field. This makes them searchable only by means of careful keyword searching, done via quotation marks. It's not ideal but it nominally works. What it can't do is give you a clickable link that is indexed. A locally defined 901 through 907 MARC tag could, in theory, allow for this. I suspect Open Source ILS'es might more easily enable libraries to make better use of the 901-907 locally defined MARC tags, making them indexable and clickable.

This is what should have been done to begin with. But that would have required having a full-time cataloger and a full-time systems librarian who worked closely together and better understood the rules...a situation that hasn't been an accurate description of our personnel situation at our library for quite some time; until now, that is.

Learning more library tools.

I am beginning to learn more Library tools commonly used in Tech Services. I am wading my way through Error Reports generated by our vendor BSLW. With the gracious help of my E-Resources Librarian colleague, I've been learning the basics of using Voyager Select, MARCedit, and Record Reloader to do global-style edits to multiple records simultaneously. This enables me to do big fixes without having to do record-by-record editing, which is much slower and plodding.

I finally am getting the hang of this, and am now less dependent on my E-Resources Librarian colleague to make these kinds of large set edits. I know my colleague was always glad to help, but I'm relieved I don't have to keep asking her for every one of these jobs. It IS complicated, and it definitely deserves its own chapter in the Cataloging Manual because it's so essential to database management. I'm looking forward to writing that chapter, with plenty of screen shots.

I even managed to fix badly-coded MARC tags...610s that were mis-coded as 650s, or moving obsolete 440s to updated and validated 810s. It's also useful for updating children's LCSH to "adult" (i.e. standard) LCSH. Some of this is challenging because adult LCSH splits the terms into two distinct headings, and these have to be evaluated on a case-by-case basis...which is a little frustrating, but it's also why it requires a professional cataloger such as myself to make those judgment calls.

The Error Reports also uncovered badly misspelled headings; even 500 field notes that were accidentally mis-coded as 650 subject tags. The original basefile reports also hoovered up a lot of records that no longer exist in the database due to withdrawal projects, etc. I've begun to clue in on what records are likely to be currently bogus and just skip over them; I'll mark through bogus bib numbers with a colored marker, usually at the start and finish of a suspected string, as a visual clue to myself that those which fall in between are also likely bogus.

I'm trying to approach some of these questionable headings with the ethic of "First, do no harm". I notice that on the theses and dissertations, some of the topics addressed are so specific that it falls between the cracks of LCSH. I try to test if I can re-code them as MeSH and achieve validation that way, or of not convert the field to a 653 rather than delete it outright. I tend to tread lightly in the area of natural science, in areas I'm less familiar with. I try to focus on topics I know best first.

I've also noticed that some things were coded as 650s that are more properly classed as uniform titles in the 630 field. Not all uniform titles have authority records but if it is justified by the chief source of information you keep it.

I'm saving the serials error reports for last, because that will get very complicated and difficult.

With less material coming into our door for cataloging, this more intellectual work of database cleanup combined with quasi-authority work is basically our fallback. We now have the opportunity to work on this because of the dearth of incoming materials and it will improve the performance of the catalog. I look forward to working with our new Systems Librarian to improve catalog performance and tweak the result sets, etc.