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.
Migrating to a new integrated library system? Library software, such as ILLiad, not connecting to your catalog? Don’t make my mistake and assume your public access catalog equals your library’s z39.50 connection.
The Library of Congress has a great search tool buried in their z39.50 gateway page that can test your z39.50 connection: http://www.loc.gov/z3950/test.html
If your test has errors, you either have the wrong information or something is amiss on the server/setting side.
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.
OCLC Connexion has a way to automatically add collection codes above the call number to make printing labels easier. So for example, a spine label will read:
This is accomplished by defining an automatic stamp for each oclc holding library code.
Open OCLC Connexion Client -> Tools -> Options -> Printing -> Label Options -> Define Automatic Stamps