Cataloging in a Shared Bibliographic Environment: Opportunities and Challenges

Jessica LeeValdosta State UniversityMay 15, 2014Cataloging in a Shared Bibliographic Environment: Opportunities and Challenges

2

3Preparing for the MergeSteps to complete before merging 34 catalogs into one:OCLC ReclamationCreating a tag tableDecisions regarding local authoritiesTesting! Testing! TestingCreate statewide guidelines for cataloging4Tag Table

Saving Your FieldsFCLA/FLVC made the decision to use $5 to save/protect certain fields that could contain local and unique content. Initially, this was used to protect the fields, it no longer does this. However, all of the SUS have their OCLC profile to not overlay certain fields. Cataloging in a Shared BibTakes longerMore steps. First must search in the local catalog THEN search in OCLC to make sure the record matches the piece in hand. Manually add holdings. If necessarily overlay, but pay attention to fields that could be lost with overlaying. Suggest printing out records to staff before overlaying and keep test database on everyones computer to verify old fields if lost. Problems While Cataloging Duplicate recordsSerials can have up to 30+ records for one titleBefore a change, there were duplicate fields (440/490 0/490 1; 700s) Ex. 700 1 Lee, Jessica E. 700 1 Lee, Jessica, 1987-Ex. 440 0 Journal of Library Science 440 1 Journal of Library Science 490 0 Journal of Library Science 490 1 Journal of Library Science Overlay ProtectionLeft column Protect on Overlay Right column Recd $5 in SB merge

Faculty/Librarian FeelingsOut of all of the people who were asked how they felt about working in a shared bibliographic environment, only ONE person liked the change. Workflows are starting to get better with state guidelinesWhole process can be stressfulNot sure if it saves time, maybe once database is cleaned upUltimately doesnt save time or moneyOne librarian believes the OCLC reclamation aggravated the multiple record problem Faculty/Librarian OpinionsWorkflows are okay, if you allow duplicate records for institution and dont try to make the database perfectOne catalog was inevitable, but it is ONLY the backend. It can be more effective for borrowing?Still a work in progress, two years laterA major advantage is that all of the 12 SUL MUST communicate with each other about bibliographic control across the state. Mucky records and older records look worse but only to catalogersIt was better to have waited to add the smaller colleges, it have figured out all the kinks and how to work effectively. 13Staff OpinionsDo you believe your workflow became changed easier when FSU merged their catalog into Shared Bib?

What challenges did you face?

Staff OpinionsDatabase is cluttered either with too many fields in a bib and/or too many records in the database. It helps with withdrawing, to see what other institutions own for withdrawing. Global withdrawing is near impossible.Previously there was the possibility of items being accidentally linked to the wrong institutions holding Can accidentally lose fields

When searching for your record, its hard to find your institutions record because there may be 38 records for New York Times Book Review in the union catalog and it would be easier to just search your institutions database. 15Key Points After the MergeMaintenance of the shared catalog is the responsibility of all SULs contributing to the file, with the assistance and support of the Florida Virtual Campus. This includes the creation or downloading of records in the catalog, editing, and deleting data. Each institution should be mindful that any bibliographic data altered in the catalog may affect the accurate representation of another SULs materials and avoid making arbitrary edits. SULs should use caution when editing a shared record to match an item in hand, as when enriching any cooperative database.Maintenance of holdings, item, and order records in the shared catalog is the sole responsibility of the inputting institution. This also applies to local notes in the bibliographic record.-p.5-6 Shared Bib Guidelines

Key Points After the MergeLibrarians wished they had worked on testing more to find more problemsThey also wish they had figured out the batch loading process before implementation as it is still a problem two years later. Bright Side of ThingsTwo people pointed out that although the database looked cluttered for catalogers. This was seen through duplicate records and fields. However this was not obvious to patrons.

Patrons may see duplicate records but only in the union catalog, something that already happens. PDA WorkflowsThe problem: there are many PDA records in the shared database but the inputting libraries do not want other SULs to share these records. The presence of these records means that other SULs cannot automate the loading of e-book records.Newly entered PDA records have the status of DISCOVERY RECORD, but there is currently no automated way not to match on these records. Older records lacking the status field have to be examined individually to figure out if they are PDA records. Currently, PDA records--both with and without the status field--result in wasted time and more duplicate bibs in the cooperative database.Long-term solution: PDA records should be loaded into the discovery tool rather than into Aleph. This is a good solution going forward.A possible short-term solution: This is a possible solution only if the ISBN is not crucial to the PDA projects. So we need to hear from PDA libraries on how they use ISBNs in their workflows.We think it would help the rest of us who are trying not to load duplicate records if the ISBNs could be removed from PDA records. This would solve the problem for the SULs who load eocrs which match on ISBNs. Removing ISBNs from PDA records seems to us to be a fairly easy global change for FLVC to do.Another variation on this suggestionprobably a better choice--is to move the ISBN to $z in the 020 field. We tested the ISBN match and it does not report a match when an ISBN is in $z but does match when in $a. Once again, FLVC should be able to pull a record set and do a global change.Another possible short-term solution: This involves setting up P_file_90 so that it can match on both ISBN and STA. If FLVC could write a script so that P_File_90 would not load a record when the status field is DISCOVERY RECORD, and further if FLVC would pull a record set of PDA records that lack the correct status field and add the STA field, that would solve the entire problem right now.Another long-term solution: Consortial purchasing of e-book packages would make the provision of bib records easier for all SULs. That way there would be just one bib for each title and the current problems of loading and encountering duplicates would be solved.The best possible long-term solution: Share bibliographic records--period.https://sharedbib.pubwiki.fcla.edu/wiki/index.php/PDA_WorkflowsThe problem: there are many PDA records in the shared database but the inputting libraries do not want other SULs to share these records. The presence of these records means that other SULs cannot automate the loading of e-book records.Newly entered PDA records have the status of DISCOVERY RECORD, but there is currently no automated way not to match on these records. Older records lacking the status field have to be examined individually to figure out if they are PDA records. Currently, PDA records--both with and without the status field--result in wasted time and more duplicate bibs in the cooperative database.

Another variation on this suggestionprobably a better choice--is to move the ISBN to $z in the 020 field. We tested the ISBN match and it does not report a match when an ISBN is in $z but does match when in $a. Once again, FLVC should be able to pull a record set and do a global change.Long-term solution: PDA records should be loaded into the discovery tool rather than into Aleph. This is a good solution going forward.A possible short-term solution: This is a possible solution only if the ISBN is not crucial to the PDA projects. So we need to hear from PDA libraries on how they use ISBNs in their workflows.We think it would help the rest of us who are trying not to load duplicate records if the ISBNs could be removed from PDA records. This would solve the problem for the SULs who load eocrs which match on ISBNs. Removing ISBNs from PDA records seems to us to be a fairly easy global change for FLVC to do.

Another possible short-term solution: This involves setting up P_file_90 so that it can match on both ISBN and STA. If FLVC could write a script so that P_File_90 would not load a record when the status field is DISCOVERY RECORD, and further if FLVC would pull a record set of PDA records that lack the correct status field and add the STA field, that would solve the entire problem right now.Another long-term solution: Consortial purchasing of e-book packages would make the provision of bib records easier for all SULs. That way there would be just one bib for each title and the current problems of loading and encountering duplicates would be solved.The best possible long-term solution: Share bibliographic records--period.

For more information on the cataloging guidelines and procedures for State University Libraries of Florida :

https://sharedbib.pubwiki.fcla.edu/wiki/index.php/Cataloging#Shared_Bib_Cataloging_Guidelines