Home » Posts tagged 'cataloging' (Page 2)
Tag Archives: cataloging
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.
Why Does OneSearch Say We Have the Electronic Book?
We’re finding that the Merck Manual is in our results as an e-resource but we only have it in print. Why does this happen?
OneSearch interprets cataloging quite literally.
In this case, the MARC record contains this 856 field (full record):
85641 $uhttp://www.merck.com/pubs/mmanual%5Fhome2/
The second indicator has a mission-critical role (MARC 856 field @ LOC)
- # – No information provided
- 0 – Resource
- 1 – Version of resource
- 2 – Related resource
- 8 – No display constant generated
OneSearch interprets all 2nd indicator values EXCEPT 2 as a version of the e-resource. Since, in the case above, the 2nd indicator = 1, OneSearch reports that the e-resource is available.
If a link is NOT to an actual e-resource, but links to related content, the 2nd indicator should be a 2.
There is one exception. Sometimes tables of contents and other materials are classified with 2nd indicator = 1, that is, a version of the resource. In that case, in order to avoid OneSearch reporting that the e-resource is owned, both of the following must be true:
- at least one of these note subfields must appear: $3, $y, or $z
- one of these note subfields must contain one of the following texts:
- Table of contents (or Inhaltsverzeichnis or Table des matières or Indholdsfortegnelse)
- Sample text
- Publisher description (or Klappentext)
- Book review
- Contributor biographical information
The most common cataloging for these at CUNY
- 85641$3 for “Table of contents” and “Sample text” notes
- 85642$3 for “Publisher description” and “Book review” notes
Before reporting this type of issue to OLS, please check the record metadata with your cataloger.
If the reason for the problem is not obvious from the cataloging and a work order is opened, please copy the 856 field into the work order.
This post was originally published on 29 April 2015. We updated it on 18 August 2015 to reflect the latest information regarding the texts which do not indicate an e-book (for example, klappentext).
New in OneSearch: Journal Issue Filtering
Problem
Years of journal issues can be impossible to wade through when trying to locate specific issues.
Solution
Filters on Location, Year, and Volume.
This tool was already available in the CUNY Catalog and has now been added to OneSearch, too.
Now, when there are sufficient issues to make filtering useful, filters will be offered above the issue list, as seen below (to view issues, open the “Locations” tab):
Source
This filtering, both in the OPAC and in OneSearch, is based on three Aleph item fields:
- sub-library
- volume, aka Enum.Level.1(A)(Vol.) or
enumeration-a - year, aka Chron.Level.1(I)(Year) or
chronological-i
Missing Filters?
There are two situations in which filtering may appear incomplete.
- missing volumes and/or years
- missing filter selection boxes
1. Missing Volumes and/or Years
If you select volume 181 in the example above, it appears that Baruch does not own the issues. However, if you select the year 2008, the result clearly shows that Baruch does own volume 181 and the issues are listed.
This problem is caused by an empty Enumeration Level 1 (Volume) field in Aleph:
This is an example of how enhanced software and search capabilities make consistent cataloging more important than ever.
2. Missing Filter Selection Boxes
This is not actually a problem. Filters do not display for all periodical results.
Filters appear when there are sufficient issues to make filtering useful. The exact threshold (number of issues) at which filters are offered is not documented, but testing shows that the lower limit is definitely greater than four. In one example we found during testing, there are two locations – one with two issues and one with five issues. In this case (two locations, total of seven issues), the filters do display.
Also, if there is only one location or one volume or one year in a record, then that individual type of filter (location, volume, or year) does not display.
Behind the Scenes
The metadata cataloged in Aleph gets communicated to OneSearch in XML format. This is the item record for the record mentioned above, showing the underlying data structure (note the empty enumeration-a field):
<item>
<rec-key>000637362006890</rec-key>
<barcode>31716004953919</barcode>
<sub-library>Baruch Periodicals</sub-library>
<collection>PER</collection>
<item-status>02</item-status>
<note/>
<call-no-1>$$hShelved$$iby title.</call-no-1>
<call-no-2/>
<description>v.181 (2008:May-June)</description>
<chronological-i>2008</chronological-i>
<chronological-j/>
<chronological-k/>
<enumeration-a/>
<enumeration-b/>
<enumeration-c/>
<library>CUN50</library>
<on-hold>N</on-hold>
<requested>N</requested>
<expected>N</expected>
</item>
Why you should not remove a lost item record in Aleph
If you’re considering deleting a “lost” item from the catalog, consider this: removing a “lost” item record also removes its circulation history! This affects library circulation statistics and item counts. Item records also contain a “date last returned” field that can be used to identify items that no longer have relevant circulation history. This information is included in reports listing items with a specific Item Process Status (IPS).
When working with a lost item, you should instead mark it with an appropriate IPS. Lost items can be flagged as missing in transit, lost/paid, lost, withdrawn (“weeded”), or suppressed. Local technical services staff should determine which IPS is most appropriate to classify a particular item in the catalog.
To ensure that a lost item record is not removed by mistake, a new automated process was introduced with Aleph v21 so that when all lost charges are resolved/removed, any remaining loan record will eventually be removed. This also ensures that a lost item would not be listed “on loan” in the OPAC when it is actually lost or missing.
Find information about item process statuses, lost items, and more on the OLS Support Site.
