Home » Posts tagged 'quality control'
Tag Archives: quality control
OneSearch, E-Resources, and Dedup
Over the winter break, OLS applied a major improvement to OneSearch results: we “de-deduped” many e-resource records!
The Problem
As OneSearch was initially configured, it applied its dedup process to all records equally, whether they were print or electronic.
What is dedup? The dedup process allows OneSearch to present a single result when the identical resource is held by multiple schools. Multiple records are merged into one display record. This is useful in the case of print resources, allowing the system to offer all CUNY locations to the user in one result.
However, this proved a major problem for e-resource records as the merged data includes the MARC 856 fields (which often provide links to electronic resources). OneSearch uses these fields to create a “View Online” button which links to full-text whenever the underlying metadata indicates this is the purpose of the field (see Why Does OneSearch Say We Have the Electronic Book?).
Deduped e-resource records with multiple 856 fields included in the merged records made it difficult for OneSearch to determine the correct availability for many deduped records. This resulted in the dreaded Full text may be available, see “Details” for links availability message with its accompanying grey dot and lack of a “View Online” button:
The Solution
E-resource records whose links require proxying are being prevented from matching other records for the purpose of deduping. This allows each local view to accurately identify the availability status of its e-resource:
The solution was only applied to records which require proxying on the assumption that e-resources that do not require proxying are freely available to everyone and should be shared with everyone.
The Caveat
Please note that this solution works best in the local school views. A version of the problem still exists for many records in the CUNY view. Instead of a single, deduped record, the CUNY view now displays a group of records (as they are now FRBRized instead of deduped):
Clicking on the title will take the user to a list of individual e-resource records. Records which are only available via a local library will still show the Full text may be available message in the CUNY view.
If you run across any problems, please be sure to report them to OLS by opening a work order with the CUNY Service Desk.
New in Aleph GUI: Checking URLs for Errors
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:
- check a URL for validity
- 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.
