Cataloging_in_a_Shared_Bibliographic_Environment.pptx
Download
Report
Transcript Cataloging_in_a_Shared_Bibliographic_Environment.pptx
Cataloging in a Shared Bibliographic
Environment: Opportunities and
Challenges
Jessica Lee
Valdosta State University
May 15, 2014
Preparing for the Merge
Steps to complete before merging 34 catalogs into one:
1. OCLC Reclamation
2. Creating a tag table
3. Decisions regarding local authorities
4. Testing! Testing! Testing
5. Create statewide guidelines for cataloging
Tag Table
Saving Your Fields
FCLA/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 Bib
Takes longer
More 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 everyone’s computer to verify old fields
if lost.
Problems While Cataloging
Duplicate records
Serials can have up to 30+ records for one title
Before a change, there were duplicate fields (440/490 0/490
1; 700s)
Ex. 700 1 Lee, Jessica E.
700 1 Lee, Jessica, 1987Ex. 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 Protection
Left column “Protect on Overlay” Right column “Rec’d $5 in SB merge”
Faculty/Librarian Feelings
Out 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 guidelines
Whole process can be stressful
Not sure if it saves time, maybe once database is cleaned up
Ultimately doesn’t save time or money
One librarian believes the OCLC reclamation aggravated the
multiple record problem
Faculty/Librarian Opinions
Workflows are okay, if you allow duplicate records for
institution and don’t try to make the database perfect
One catalog was inevitable, but it is ONLY the backend. It
can be more effective for borrowing?
Still a work in progress, two years later
A 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
catalogers
Staff Opinions
Do you believe your workflow became changed easier when
FSU merged their catalog into Shared Bib?
What challenges did you face?
Staff Opinions
Database 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 institution’s holding
Can accidentally lose fields
Key Points After the Merge
“Maintenance 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
SUL’s 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 Merge
Librarians wished they had worked on testing more to find
more problems
They also wish they had figured out the batch loading process
before implementation as it is still a problem two years later.
Bright Side of Things
Two 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 Workflows
The 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 eocr’s 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 suggestion—probably 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_Workflows
The 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 suggestion—probably 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 eocr’s 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/Catalogi
ng#Shared_Bib_Cataloging_Guidelines