The Office of Library Services is pleased to report that we have completed a thorough review of 856 (URL) fields in our catalog. On Thursday, November 5, we emailed the Cataloging Committee members explaining how to access their school’s error list in the Aleph task manager and providing details about the results.

Project Goals

• a school-specific report listing all the problem fields
• a method for temporarily removing these broken URLs from OneSearch
• an easy method for catalogers to update Aleph and OneSearch once the 856 fields are corrected
• an easy method for catalogers to obtain updated lists of any remaining broken 856 fields

To that end, suspect 856s fields have been marked in the Aleph cataloging record with an 856 sub-field ($zBroken Link). For example:

85641$ahttp://state.tn.us/correction$zBroken Link

Until the link is fixed and the subfield is removed, the URL will not appear in OneSearch.

When the cataloger corrects the link in the 856 field, they will also remove the Broken Link subfield and, later that day or the next day (depending on the time of the update), the link will reappear in OneSearch.

While we have provided a list of broken links for each campus, any Aleph power user can easily get an updated list via an Aleph CCL (Common Command Language) search. For example, this search will output all broken links owned by CUNY Central (OWN=AL):

WUR="broken link" AND WOW=AL

Recommendations

To help you get started, we are recommending that catalogers prioritize the error list in the following way?s

1. Troubleshoot e-resource-only records first (before mixed print+electronic). If these don’t work, the records have no reason to exist.
2. Identify 856s in old records (government docs and books) that point to non-full-text content (like table of contents). Consider removing those without assessment.
3. Identify 856s for online versions of print material. Update if possible, otherwise remove the links (PURLs often don’t work).

Additional Notes

In September, we wrote about new error checks for the 856 field that had been added in the Aleph GUI. These error checks allow the cataloger to open a record, press CTRL-U (Check Record), and get an error report showing the type of error. Clicking on that error will take them directly to the problematic 856 field.

That September blog entry also lists all the MARC fields which can contain a URL. At the beginning of this project, we reviewed the content of all those other URL fields (505, 506, etc) and found that their use was extremely rare at CUNY. For that reason, we only ran this URL checking process on 856 fields.

Since we have added the GUI-based URL checks, we do not anticipate running this process more than once a year.

Most links in our catalog are in the MARC 856 field. Many of these are added to the catalog by batch record loads, but some are added by catalogers.

URLs manually entered in Aleph by catalogers will now be checked for errors as part of the standard Aleph GUI error checking procedures.

This has been made possible by the addition of the following new tests to the Aleph Cataloging module:

1. check a URL for validity
2. check that the URL was not mistakenly entered in subfield a ($a)

Checking a URL for Validity

In addition to the 856 field, the URL subfield ($u) can also be used in the following fields:

• 505 (Formatted Contents Note)
• 506 (Restrictions on Access Note)
• 514 (Data Quality Note)
• 520 (Summary, Etc.)
• 530 (Additional Physical Form Available Note)
• 540 (Terms Governing Use and Reproduction Note)
• 545 (Biographical or Historical Note)
• 552 (Entity and Attribute Information Note)
• 555 (Cumulative Index/Finding Aids Note)
• 563 (Binding Information)
• 583 (Action Note)

While $u is rarely used in these fields, this validation process will check any URLs that are entered into $u of these fields, too.

The error will be expressed as a URL error code (aka HTTP status code) — see the example below.  Lists of the common URL errors and their meanings, such as 404 “Not Found”, can be found on the web.

Checking that a URL is Not in $a

The URL validity check described above only looks at URLs that are located in $u.  It will never cause an error message when the URL is entered in the wrong subfield.

One of the more common 856 URL errors is that a URL is entered in $a by mistake.  In fact, 856 fields rarely have need for $a.

For this reason, we have created a second check that looks for the existence of $u when $a exists in the 856 field.

This check is only run on field 856 because the 856 is overwhelmingly the most common location of URLs in our catalog records.

The New Checks in Action

These two new checks are both run along with other standard Aleph error-checking:

• by saving the record (example of the validity check)
  
• from anywhere in the record, go to the Edit Actions menu > Check Record (example of the subfield check)
  
• with the cursor in the 856 field, go to the Edit Actions menu > Check Field

We hope that these new features will be useful to you and aid in our on-going efforts to make e-resources more easily accessible for end-users.