Home » Posts tagged 'cataloging'
Tag Archives: cataloging
Aleph Item Process Status: Bindery status
The Aleph Item Process Status (IPS) in Aleph is sometimes misunderstood, as it is sometimes (but not always) more than a display field. The functionality built into some of the IPS is complex, so it will probably be best to approach them separately. Let’s please take a look at the Bindery related statuses:
BD At Bindery BP In Repair PB Binding Preparation SB Sent to Binding
While these statuses are not assigned by every CUNY library in the same way, we know that all four cause items to function in Aleph the same way. In Aleph, they block items from being CLICS eligible. They suggest that the items are not readily available. (The only difference between these four is the screen display text.)
These IPS will all migrate to our new LSP in the same way. These Aleph Item Process Statuses will ONLY appear as a comment on the items for staff to see – assuming that they look up each individual item. These comments will give no indication to patrons that these items are not actually available on the shelf. Also, the items would follow the circulation policy of their collection. For example, patrons could suddenly place holds for these items, if they are in a request-able collection.
I discussed the following plan with the Director of our new LSP’s Data Migration Services. She concurs that the below is probably the best method for migration of these particular statues. (She has a history of work in our new LSP, as well as with Aleph.)
It would be recommended to set up in Aleph a collection called “Bindery,” or some similar verbiage of your library’s choosing. The on screen description should indicate as intuitively as possible to patrons that the items are unavailable due to being out for re-binding or repair.
Next, all of these items should be placed in this location of “Bindery” as a temporary location. The Aleph Item Process Status should then be removed BEFORE we migrate to Alma. When the item returns to the library at some future date, one only needs to remove the temporary location check box. The items will revert back to their permanent location as listed in the holdings record.
An added benefit is that this will also work well in our current Aleph environment. It will communicate clearly to patrons that items are temporarily unavailable, or at least not available now. Reverting back to a permanent location (in Aleph) this can be done manually or as a batch process. (In Alma, you can also set the temporary location to automatically expire at a pre-selected date.)
This would not apply to all Aleph IPS. Some are very much more than just a display field. There is software functionality tied to the Item Process Status. We will not want to lose that functionality in Aleph, nor in the new LSP. For example, we would specifically not want to use a temporary collection location for misplaced (missing, searching, lost, etc.) items.
Related topic: Aleph IPS – New Book
Print to Electronic record conversion for the new Library Service Platform
Moving away from Aleph to a Library Services Platform requires preparation BEFORE data migration. One important pre-migration goal is to separate print items and electronic items out at the title level.
Aleph, like many legacy ILS systems, handles electronic and print records using the same data structures. We have bibliographic, holdings and print records.
In a Library Services Platform, electronic records are handled in a very different way. The data structures are different, as they look to manage these records in a more sophisticated way. For example, the link resolver is taken into account. This requires that the current record structures must be transformed at the time of migration.
There are a number of titles in CUNY’s Aleph catalog which have both print and electronic items on the same bibliographic record. In some cases physical items are incorrectly identified as electronic records. At least some electronic records incorrectly identified as physical print items. There are also physical print items where the library also has access to full electronic text.
As part of your preparation, we are looking to separate print items from electronic items at the Bibliographic level. One of the main reasons is that we need to migrate there records in a very different way. This impacts more than the catalog records. Some titles have serial subscriptions. Both serials patterns as well as acquisitions orders are impacted.
As we look to other libraries that have successfully migrated we find a repeated recommendation. Separate your print items from electronic items before migration. It absolutely requires a great deal more manual work to sort out and rebuild your catalog records if a library does not. For example, under certain conditions electronic items can show up “as if” they are physical items, which is a problem.
A second reason is that print and electronic records can have separate OCLC numbers. OCLC numbers become increasingly important in an LSP environment as the primary match point. This will facilitate functionality such as replicating the CLICS borrowing that we currently enjoy.
There are a variety of problems that arise by not separating these records. This goes beyond not following modern RDA standards. In presentation after presentation libraries keep pointing out the need to get this done. Let’s please learn from their history and not repeat their mistakes.
We will be talking more about this during the coming year in the Cataloging and Acquisitions Committee meetings. (Both areas will be impacted, in their own ways.)
OneSearch, E-Resources, and Dedup
Over the winter break, OLS applied a major improvement to OneSearch results: we “de-deduped” many e-resource records!
The Problem
As OneSearch was initially configured, it applied its dedup process to all records equally, whether they were print or electronic.
What is dedup? The dedup process allows OneSearch to present a single result when the identical resource is held by multiple schools. Multiple records are merged into one display record. This is useful in the case of print resources, allowing the system to offer all CUNY locations to the user in one result.
However, this proved a major problem for e-resource records as the merged data includes the MARC 856 fields (which often provide links to electronic resources). OneSearch uses these fields to create a “View Online” button which links to full-text whenever the underlying metadata indicates this is the purpose of the field (see Why Does OneSearch Say We Have the Electronic Book?).
Deduped e-resource records with multiple 856 fields included in the merged records made it difficult for OneSearch to determine the correct availability for many deduped records. This resulted in the dreaded Full text may be available, see “Details” for links availability message with its accompanying grey dot and lack of a “View Online” button:
The Solution
E-resource records whose links require proxying are being prevented from matching other records for the purpose of deduping. This allows each local view to accurately identify the availability status of its e-resource:
The solution was only applied to records which require proxying on the assumption that e-resources that do not require proxying are freely available to everyone and should be shared with everyone.
The Caveat
Please note that this solution works best in the local school views. A version of the problem still exists for many records in the CUNY view. Instead of a single, deduped record, the CUNY view now displays a group of records (as they are now FRBRized instead of deduped):
Clicking on the title will take the user to a list of individual e-resource records. Records which are only available via a local library will still show the Full text may be available message in the CUNY view.
If you run across any problems, please be sure to report them to OLS by opening a work order with the CUNY Service Desk.
