Thanks a lot, Sarah!
It took me a while to follow all the links and read most of what’s out there. I am interested in the project Cornell has undertaken and hope to learn more, purely from a cataloger’s perspective, how the current system of yours facilitates searching. Since the backbone of Cornell’s subject authority file is LCSH, I think searching in OPAC will work just fine.
The only issue that I am concerned about is when you get “updated” bibs from OCLC via WorldShare, you may run into mixed 6XXs as shown in the snapshot I gave in the beginning of the thread. But again, your system seems to be able to handle it leniently. Whatever a library user types in (barring obvious spelling mistakes), the system will retrieve what’s in 6XXs. Hence,
History | African American
History | United States | 20th century
are searchable (J $2 bisacsh) terms. Even incorrect headings like
Civil rights movement
African Americans | United States
are there for grabs, so long as they are in 6XXs.
This (the presence of split name and subject files), however, is commonplace nowadays in academic libraries in North America. Too many vendor records being poured into OCLC, individual institutions simply don’t have enough catalogers to examine and correct/revise subject headings. And my point is? Add a voice to our common cause: advocate cooperative cataloging and appeal to library administrators, whenever there’s an opportunity, to hire more catalogers (wishful thinking, I know). But I am sorry it needs to be said and worth repeating. Quality is important. What a glaring irony that, with the full implementation of RDA, institutions have been inexplicably cutting cataloging staff!
This is hard enough to reconstruct in my memory that I am going to get some things wrong, but I’ll give it a try.
· The best place to get up-to-date info on what’s going on with FAST is either to query the listserv FACETVOC-L or bug somebody on the FAST Policy and Outreach Committee, https://www.oclc.org/en/fast/committee.html
· You can see our in-house procedure at https://confluence.cornell.edu/pages/viewpage.action?pageId=326379517
· As for “arduous and complicated,” let me quote our Batch Processing person, Gary Branch:
· “While we had several conversations with OCLC Research Staff prior to conversion, I did very little on the automation side to prepare. I had our programmer pull out our bib ids in increments of half million records, transferred the files to a specified FTP server and OCLC did the conversion of our 6xx LCSH. Loading was a bit tricky as the catalog is not static. We decided that the safest thing to do when OCLC returned our bibs was to copy the fast headings from the returned bib, pull that current bib, and have the script copy the fast headings to the current bib and maintain any edits to the record in the meantime. One of the reasons I did a lot of the loading over Xmas break was that the catalog was static during that time frame making it safer to do this. Early in the processing we were picking up files late in the evening for the same reason. From an automation side it was a large scale conversion, but not very complicated programmatically.”
· For all of our legacy 600s and 610s, if OCLC could not make a match with a name in the NAF, they still made a FAST heading, using an extension. The extension they used is not quite the same as the one in our procedure for 600/610 access points without a FAST equivalent (the 600 17 $a Kovari, Jason $2fast/NIC example). If OCLC couldn’t make a match with something in their file, they sent us something like this to load:
600 17 Lee, Corey ‡2 fast/NIC/NAC
NIC is our NUC code and NAC, of course, stands for Not Authority Controlled.
So we can tell the difference between cataloger-assigned /NIC subject headings and mass-conversion assigned NIC/NACs. We asked OCLC to send us a file of all our NIC/NACs and I reviewed them when we got them. It was way too many to really deal with. From my sample of several hundred, it seemed like 50% were us screwing up on our LCSH and making a typo that prevented a FAST match, and 50% were legitimately not in FAST (at least not at the time of cataloging).
The good thing about these /NIC and /NIC/NAC extensions is, the public catalog doesn’t care. As long as the subject heading has second indicator 7 and $2 fast at the end of it, it’s getting a facet. So our personal and corporate names and our improvised geographics are all behaving exactly like real FAST, only without the identifiers.
· In the mass conversion, if OCLC could not make a match on a particular topical heading, they converted all the rest of the headings and just left the problematic one off the array.
· One sadly common legacy error was for a cataloger to say something like Community development $z Jakarta (Indonesia). FAST doesn’t turn a hair. OCLC accurately pulled out two facets, Community development and Indonesia $z Jakarta.
· Going forward from the mass conversion, we use OCLC’s WorldShare. If a record started life with LCSH only, we do not ask a cataloger to add FAST. OCLC will crawl their database and add FAST, and when they do, we get the update through Worldshare. Similarly, if a record starts life with us as FAST only but a member library adds LCSH later on the master record, we get that update through WorldShare. We do have some records that we expect will only ever have FAST throughout their lifetime, and those subject headings appear as both facets and in the browse index.
· One newer feature of the searchFAST tool that I love is the importFAST button: http://fast.oclc.org/importfast/
--Sarah Ross, Cornell
It’s great to see how FAST headings are used in Cornell’s library catalog. The actual implementation (beginning from 2014- ?) must have been arduous and complicated. I am surprised that your institution has even done a large-scale retrospective project by converting all LCSHs (in older records, wherever possible) to FAST headings. Could you divulge a bit more about the process?
1) Did you do the entire conversion locally or did you re-import bib records from OCLC (older records, but newly “enhanced” with FAST headings)?
2) How did you deal with “left overs”—subject terms that are either “Invalid/See reference” (“Central banks” [--> Banks and banking, Centro], “Epistemology” [--> Knowledge, Theory of], Gender studies [--> Gender mainstreaming) or simply resist “slice ‘n dice” process (valid LSCH [e.g., terms from NAF], but not/not yet in FAST vocabulary, such as “Eyes on the prize (Television program)”)?
3) What happens if you encounter bibs with solely FAST headings (singletons, such as “Philosophy,” “Ethics,” “Space and time”, etc., don’t count; only consider such text strings: “Philosophy—History—Bibliography,” “Art, Modern—20th century—Exhibitions”, “Homer.--Odyssey—Concordances,” etc.), AND you need to re-construct new sets of LCSH headings to support “the traditional browse index on the LCSH string”?
Thank you for mentioning this, Mark. That’s exactly what we have done with our discovery layer here at Cornell: FAST in the facets area on the left hand, LCSH in the record view. We’re very happy with our implementation of FAST.
I don’t know how many complications in our implementation people want to hear about. One thing I always like to emphasize is, we have not taken away the traditional browse index on the LCSH string. Users who want to do that still can; users who want to slice ‘n dice using facets now have that tool.
110C Olin Library
Ithaca, NY 14853
email: [log in to unmask]
phone: (607) 255-5752
fax: (607) 255-6110
Another approach to FAST is to have these appear only in the facet area of the discovery system (e.g., the left side of the search results view) for filtering purposes. In the full bib record view, display only the LCSH or what have you. But I’m not aware of anybody who’s implemented their system in this way—or if this is a good use of FAST.
Mark K. Ehlert Alma: NA02
Cataloging and Metadata Primo: MT NA01
University of St. Thomas
"Experience is by industry achieved // And perfected by
the swift course of time"--Shakespeare, "Two Gentlemen of
Verona," Act I, Scene iii