This blog documents news and updates from the CUNY Office of Library Services’ Systems department. As readers of this blog, the staff and faculty at the CUNY Libraries should expect product updates and tips & tricks for making the most of the systems we support, as well as how-to information to help you achieve certain tasks. Read more about OLS »
When we released the new UI in OneSearch, we implemented a “bug report” feature to allow users to alert us to any problems they encounter while using the discovery platform. Since its implementation on 8/27/17, we have fielded approximately 917 of these reports—that’s about 10-11 reports a week. This is becoming burdensome for OLS to handle on our own so we’re changing our workflow and bringing you—the campus librarians—into the mix!
Beginning on Monday, April 8, 2019, users who submit bug reports in the OneSearch interface will receive an automatic response from OLS:
Thank you for bringing this to our attention!
We are forwarding this report on your behalf to your campus library (copied here). You should expect a response from a librarian within 2-4 business days.
CUNY Office of Library Services
The major change comes in the form of the party copied on this message: the campus library! Unlike in the past, the Office of Library Services is bypassed altogether.
We in OLS strongly believe (and the Public Services Committee agrees) that a majority of these reports require local reference intervention to address the users’ immediate needs and can almost always be resolved locally through the regular library troubleshooting avenues (e.g., report linking errors to your e-resources librarian, speak with your technical services staff about cataloging problems, consult your access services librarian for patron account issues, etc.).
Should your library be unable to fully resolve the issue, OLS will be happy to help! Just send an email to email@example.com, being sure to put the word “OneSearch” and a brief description of the problem into the subject (with a full breakdown of the presenting problem in the body of the email).
The ELUNA (Ex Libris Users of North America) Primo Product Working Group collects enhancement requests and sends out ballots to all Primo customers. CUNY votes as a single institution, with a total of 100 votes. There are 62 items on the ballot but we hope to identify the top 5-7 issues so that we may put our weight behind the issues that matter the most to us.
In order for members of the Public Services Committee to identify the enhancement requests they’d like CUNY OLS to make on their behalf, the ballot has been recreated as a survey for committee members to vote on behalf of their own institutions. We in OLS will use the survey voting results to vote on the official Ex Libris ballot.
You may review the 62 request options on the ballot (PDF) and express your preferences to your library’s Public Services Committee representative by Wednesday, April 17, 2019.
(Please pardon the duplication. This information is also being shared with the PUBLIC-SERVICES, TECH-SERVICES, and ERAC mailing lists. The Chief Librarians have also been notified.)
The Office of Library Services will discontinue the Serials Solutions (“SerSol”) MARC records service for CUNY in summer 2019.
The SerSol MARC service provides title-level bibliographic records of subscription e-resources for public access. The monthly service sends updates (changes, additions, and deletions) of the holdings, triggered by collection activations in SerSol 360 Core, to the local online catalog (i.e., Aleph) and, subsequently, OCLC. CUNY uses the service to provide title-level access to e-journals via the library’s online public access catalog (“catalog” or “OPAC”) and Primo, and also to display holdings in OCLC WorldCat.
Sending SerSol records to OCLC to sync our holdings has always been a necessary but daunting and flawed process. It involves monthly identification and extraction of records from the Aleph database for submission. Mismatched records occur often and handling the unresolved records reports is extremely time-consuming.
The new library services platform (“LSP”) offers title-level access to e-journals in Primo through its shared metadata repository. Migrating SerSol MARC records to the LSP would result in duplicate records in Primo. Subsequent deduplication of these records has proven very time-consuming and inefficient by other institutions that have preceded us in their migration to the LSP. Therefore, it has become accepted best practice to not migrate SerSol MARC records of e-journals during this process.
Because SerSol MARC records will not be in the new system, there will be no records for CUNY to send to OCLC to attach holdings in WorldCat. In order to continue our status as providers of information to the global community, especially as ILL lenders, CUNY Libraries must maintain their holdings in WorldCat by activating e-resource holdings in OCLC’s WorldShare Collection Manager (“WCM”). OLS is making every effort to help with this transition to a new knowledgebase. We are currently testing a method that may allow for a one-time migration of all SerSol data to WCM.
While OLS works on a year-long OCLC reclamation project (to update and sync the OCLC control number, the primary matchpoint between records in the LSP) for the 24 CUNY campuses, we will temporarily suspend the monthly new holdings syncing process in OCLC in order to successfully bring CUNY’s holdings up to date in WorldCat. This makes it a good time for our cancellation of the SerSol MARC records service as there is no need to extract the new/updated SerSol records from Aleph.
We recommend that CUNY Libraries begin transitioning to using the WCM to manage their OCLC holdings now so that their holdings are accurate in WorldCat come summer 2019, when OLS will cease loading SerSol MARC records into the catalog.
More details will be shared as they become available.
If you have any questions, please contact OLS.
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.
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. Should the item return for use 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.
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