Home » CUNY Catalog
Category Archives: CUNY Catalog
Advance planning for printing
Advance planning for a technical solution is the type of issue that seems worth bringing to your attention. This one applies to a library’s future purchases of printers. It may be prudent to consider only buying printers with full network connection capabilities. This allows them to be email aware, meaning that they can receive and print email messaging.
We know that in the future we will replace Aleph with something that is going to be a next-generation cloud-based system. We can predict that it will be a hosted SaaS (Software as a Service) environment, sometimes referred to as a ‘Library Service Platform’ (LSP).
Due to security concerns and technical limitations, cloud-based environments do not support direct connection of local or network printers. Instead, print jobs are sent by email to the printer for processing. (Documentation for Alma, as shown in just one example, can be found on the Ex Libris Knowledge Center.)
This may change in some future Alma enhancement, but for now one should plan for what we known to be already developed. For printing labels and circulation transfer slips, it is wiser to plan on using email aware printers.
An inexpensive network printer (aka not email aware) can continue to be productive without using Aleph or its replacement. Consider carefully whether you would really have a use for printers in some way. For example, the desktop Connexion application—used by many CUNY libraries—allows staff to batch print labels directly to a networked (or directly connected) printer.
Also, some Alma libraries are not be concerned about directly printing transfer slips and patron loan receipts. Instead, they route these emails to a dedicated staff email address, and then selectively print out (on their local network) the emails as needed.
It is up to each library to decide how this applies to their future equipment purchasing plans. It is important that the options be considered and factored into any plan being made.
If you have further questions, please contact the CUNY Office of Library Services.
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
Planning to remove Lost Items from the Aleph catalog?
If your plans include using any batch processes for removing lost items records, please consider first removing titles that are suppressed with an Item Process Status of “LO” or “LP.” We can use a batch process with titles.
We can use a batch process for items if and only if we have first removed the titles.
If a title has more than one item, and all of the items are suppressed (Aleph Item Process Status = LO, LP, SU, WD, or CA), the title will be suppressed. We can safely remove these in batch by tagging the Bibliographic records with STA=OLSDELETE. (This suppresses titles, and at the start of the next month completely removes those records, after withdrawing your library’s holdings from OCLC for that title.)
If we have run this batch process, we know that the remaining LO and LP items are on titles where the bibliographic record has at least one active item remaining. This means we can safely use the batch process to remove these items. This batch process removes the items and, if there are no items remaining on the holdings, it also removes the holdings record. If there are no holdings left for the title, it removes the Bibliographic record.
The dangers come from three potential issues.
If we just remove items, holdings and the bibliographic record, without removing the holdings from OCLC, we do not know anything more about the deleted title. We do not know which holdings to unset. This is not a concern IF we have first used STA=OLSDELETE.
A second danger would be IF the item record is not linked to a holdings record, it will not know which holdings record to remove. However, we can identify those unlinked items as the Holdings number will appear in our custom listings as ‘000000000CUN60.’ (Since we recently ran a fix for holdings records, we are down to roughly 60K items not linked to holdings across CUNY; a third of those are at a single institution.) These small numbers of items can be easily handled in advance.
Looking at a listing (for your library) of all items currently on loan but never returned by patrons, we see that none of them have an Item Process Status for suppressed, lost, not returned, or missing. These items are not misplaced, and instead have a loan status of ‘Not returned by patron.’ These items are not suppressed, and neither are their titles. Please do not assume these might be lost by batch removals when done properly by a trained Aleph Admin.
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.)
Sync your Collections with your Circulation Policy – La Segunda Parte
This is the second part of synchronizing your Collections with your Circulation Policy. This work comes after you have begun as described in my previous blog post:
Sync your Collections with your Circulation Policy
Let’s say that you are finding one collection where your library has 345 items with “Aleph Item Status 01”, and 2,357 items with “Aleph Item Status 02”. Let’s also assume that each item generally has the correct circulation policy.
Of course, one would want to separate what are really two sets of items in the same collection. This will be a manual process, because someone will have to edit the holdings records. Someone might also want to check whether some of the individual items seem to have the correct circulation policy.
If we moved an ENTIRE collection to a new collection, it could easily work using a batch process. There would be no new holdings records to create.
We correct both existing items and holdings, and then run a scan to double-check & triple check. There would be a need to re-check for duplicate holdings records, as well as checking any orphaned holdings we may find.
IF we only moved PART of a collection, based on Aleph Item Status (or some other criteria) it would not work by using a batch process. We would be attempting to apply changes to both the existing items and holdings records. The Aleph functionality would not CREATE new holdings records.
This would just make a mess since you might need to add a holdings record. We could not have two items linked to the same holdings record, but with each item attempting to use a different permanent collection code. These automated Aleph functions do not add temporary locations.
For example, one bibliographic record has two items today in collection MEDIA. If we wanted to move one of these items to collection AV and leave one in MEDIA, then we would need to manually create a new holdings record. Of course one could put both permanently in MEDIA, and use a temporary location for media reserves. This requires human judgment as temporary locations should ONLY be use when the change is really temporary (meaning, time limited and to be eventually reversed).
The recommended way to proceed is to either choose a second existing collection, or add a new collection code, in order to divide these two sets of records into two or more collections. Create a collection description that clearly let’s a patron know exactly where the items are physically located. (Patrons see these descriptions in initial search results.) Then, move the smaller subset of items by editing the holdings records. Items and holdings records absolutely matter in the new LSP.
Any new collections should be added before October 15th, 2018. (This will help us make sure it will be included in the new LSP.) The work of moving items would not be needed to be completed before July 2019, but OLS would not recommend leaving it until the end of the semester or fiscal year end.
