Briefly, our library checks out a key to a public speaking lab where students can work on presentation skills. I was asked if there was a way to prevent students from checking the key out when tutors are scheduled to be in the room. After some looking, I discovered that a lot of libraries were using Aleph’s booking feature to reserve rooms. This is not surprising but interesting because Aleph’s documentation refers to reserve material and holds when detailing booking requests.
The simple setup seems to be working fine so far. I say simple because I didn’t need to implement the online reservation calendar. The bookings are just made on the backend and no one but the tutors can check out the key during and just before scheduled tutoring sessions.
I just want to note which files I updated in our 50 library for future reference.
After updating these files, don’t forget to restart the server.
There are tons of url link checkers for websites that will essentially give you a list of links that return errors (think dead links and 404 Forbidden Errors) for any given domain. I wanted to take that same concept and apply it our library catalog and its 11,000+ urls to electronic resources. Even without direct access to the backend database tables, I found a solution!
MarcEdit to the rescue. This free marc editing program has a nifty long-standing feature that verifies urls in a .mrc file. (The original posting “MarcEdit and URLs” can be found on Terry’s worklog, the creator’s personal blog.) When you run the report, it returns a list containing the contents of the “Title” and “URL” fields, as well as the Status Code and Status Message retrieved when navigating to that website. To personally make this work, I not only needed the .mrc file but I also needed to create an empty .html file before running the “Verify URL” Add-in. I also entered our system number field (001) instead of the “Title” field (245) so that I could find the exact record easier.
Before I could use MarcEdit though, I needed to pull the holding records out of Aleph. I started with the Items -> General Retrieval Form (ret-adm-01) to get a list of all of our electronic resource items. Then, I ran manage-70 Retrieve Record Keys to convert Items to Bib records. Then from Bib records to Holding records. I found that if I converted straight to holding records, the resulting list was missing a lot of records. This disparity is most likely because many of the items in question were never actually linked to the holding record in Aleph.
After converting record keys, I connected to the 60 library and ran Download Machine-Readable Records (print-03) with the “Field 1 + indicator” filled in as #####. Then, I downloaded the resulting file from the server to my local computer. In my instance, I also had to rename the file with .mrc at the end to indicate the proper format before it could be used with MarcEdit.
The result – a list of 1,005 records with errors out of over 11,000 total. Not great, but not bad for never checking these links in the past. Plus, no one had to click on each link to find all this information!
Our staff started using Aleph’s course reserve module this past summer and now the online search tool is loaded with fall courses and suppressed items. So the question was posed to me (again) on how we could just show active courses.
The simple answer is that you delete inactive courses and items no longer getting used.
However, if you want to keep some of the course information in your system, you have a few options. Here’s what needs to be done to eliminate outdated material from showing up in your course reserve (xxx30 library) search.
If you don’t want the course to show up in the results, you need to do one of the following:
- the course needs to be deleted or
- the period needs to be set to NA (not active), the end date needs to be in the past, and all items associated with that course removed from the course’s Doc List
If you don’t want the item to show up in the search results,
- Library owned books from your main collection – remove the item from the course doc list
- Dirty records for personal reserves not owned by your library – the item needs to be deleted (but don’t forget to grab usage statistics first!). You might be tempted to suppress the item but the title will still show up in the search results because the item is still attached to a bib record.
– A special thanks to LACUNY reserves roundtable for sharing their 2009 meeting minutes. Very helpful information.
If you get an XML Parse Error when trying to open/view a report in Aleph, you might need to update Java. This is definitely the case when you get a “Unable to run Saxon” error and it seems the XML Parse Error is a similar deal.
A few times I’ve had co-workers ask me a question about a record and only send me the holdings record number. At first I thought you could only search for records by their bib (aka system) number, but I have since found a way to find holding records based solely on their 001 MARC field.
- In Aleph Cataloging, switch to your holdings library (ALEPH -> Connect to… -> xxx60)
- In the record bar, type the Holding System Number you are looking for and hit enter. Note: It does not matter which tab you are on.
- The record will appear in the Records Tab!
A shout out to FLVC where I originally found the answer.
As I mentioned in a previous post, my library is implementing a campus delivery program and I just finished setting up the back end to make this process more seamless. Here’s a recount of the changes:
First, I had to define a policy and process for processing holds in our Integrated Library System, Aleph. This involved setting up automatic reports in Aleph’s “job list,” adjusting the print templates, and training the staff. The most frustrating part of the whole process was that I couldn’t determine a way to automatically send email notifications to users letting them know their hold was available for pickup. Well, there is a way to send the email if the circulation computers were set up to send emails through Aleph, but our IT team would never let this happen (and I don’t really blame them.) So, keeping this inability to send “available for pickup” notifications in mind, I moved onto the ILLiad component.
Here’s a rundown of the new ILL process for requests that the library has on the shelf.
- User submits a request for a book the library owns
- The request may end up in the Borrowing or the Doc Del Awaiting Request Processing queues depending on routing rules and how the request was placed.
- Library staff check to see if the item is owned by our library using the z39.50 feature and, if available, staff click “Copy Info” to automatically populate the call number field in the request.
- If our library has the item on our shelf, ILL staff no longer cancel the request.
- Staff route the request to the queue Awaiting Stacks Searching in Doc Del.
- When “Print Pull Slips” is clicked, a slip gets printed based on the template DocDelLoanLabels. This template was adjusted to include the user’s institution ID (as a scannable barcode), Delivery Method, and secondary address (aka campus address).
- The book is retrieved using the call number on the book.
- “Update Stacks Search” is clicked in ILLiad’s Doc Del
- Transaction numbers are scanned to update requests and route them to “Awaiting Customer Contact”
- In “Awaiting Customer Contact” staff select “Send Automatic Emails”
- For books, two different emails can generate. The template ILLDDLoanDeliveryNotify is used for users who want campus delivery (aka: they have a delivery option “Mail to Address”) The template ILLDDLoanNotify is used when users are going to come to the library and pickup their item. This reflects the delivery option “Hold For Pickup.”
- If users are using campus delivery, their item is checked out to them in Aleph using their institution ID number that’s in both Aleph and ILLiad. Then the item is delivered to the specified location on campus as indicated by the user’s secondary address.
- If users are coming to the library to retrieve their item, a hold request is placed within Aleph. Then the item is “returned” in Aleph to actually place the item on hold for the user. Finally, the item is placed on the holds shelf and can be checked out when the user comes to pick it up.
For books our library doesn’t own, the only technological step we needed to change for campus delivery was the print template and an email template. So, I updated the BorrowingLoanLabels template to include the user’s “Delivery Method” and their secondary address (ie: their campus address). I also added and customized the email template ILLLoanDeliveryNotify.
The final technological changes that were made to make campus delivery a success involved altering the website which I’ll discuss in my next post.
Did you know that you can’t just delete records from your ILS if you are using a discovery system? I didn’t. In fact, the only reason I knew that deleting records was a potential concern was a comment made in passing by a library technology person over a year ago. Even though this person came from a library that uses Voyager and Summon, I tucked this tidbit away.
Now that I am preparing our catalog questionnaire for EBSCO’s EDS and getting ready to request a data extract of our catalog for indexing, this tidbit has been bugging me. It took several investigations on both EBSCO’s and SUNY OLIS’s support sites to discover the truth about deleted records. We can delete items and holdings with no repercussion, but the bibliographic record is another story. In our case, we need to add an STA field that says “WITHDRAWN.” Then, after the catalog is indexed (once a week), we can run a report to delete these records in batches. Conveniently, we can also get a report of OCLC numbers so we can also delete our holdings from OCLC in one sitting.
So in essence, these changes have meant a complete change in workflow, a temporary pause in withdrawing items, and documented procedures for withdrawing items. And all thanks to a passing comment.