Home » Posts tagged 'metadata' (Page 2)
Tag Archives: metadata
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.
Behind OneSearch: Part 2 – View PNX and Source Records
In part two of this 3-part series about basic tools for understanding and troubleshooting results in OneSearch (Primo), you’ll find out how to view the PNX and also the source records “behind” search results. In part one, you learned about the structure of internal Primo records (PNX). In part three, we’ll show you how to use bookmarklets to easily view PNX and source records in one click.
Now that you understand Primo’s internal record structure, aka PNX (Primo Normalized XML), the next step is to learn how to view PNX. A small change to a Primo URL will allow you to view that PNX record for any record in Primo search results. For local data sources, such as Aleph and CUNY Academic Works, you can use the information in the PNX record to create a URL that will display the source data used to create that PNX record.
Primo PNX Record
Search for something in OneSearch
Pick a record in the results and click on the “Details” tab. Then click on the “open this item in a new window” icon at the top right of the “Details” frame:
(This opens the record in a full screen view.)
Copy this text:
&showPnx=true
Click anywhere in the address box:
Push the End key on your keyboard to move to the end of the URL, paste the copied text at the end of the URL, and hit the Enter key. The result looks like this:
(Click on the above image to see the result of “&showPnx=true” being added to a full screen search result display URL.)
Source Record: Aleph MARC
Now that you’ve got the PNX for an Aleph record, you can view the source MARC record in Aleph.
Examine the PNX that you opened. Near the top, you see fields like this:
<sourcerecordid>007651609</sourcerecordid>
<sourceid>CUNY_ALEPH</sourceid>
<recordid>CUNY_ALEPH007651609</recordid>
First of all, you know it’s an Aleph record because it says so in the sourceid field (CUNY_ALEPH). The sourcerecordid is the Aleph record number or “system number” (007651609).
Create that Aleph MARC record URL by placing that record number at the end of this base URL:
https://libsearch.cuny.edu/F?func=direct&doc_library=CUN01&format=001&doc_number=
For example:
https://libsearch.cuny.edu/F?func=direct&doc_library=CUN01&format=001&doc_number=007651609
This will take you to the OPAC MARC record view:
Source Record: Academic Works Dublin Core
If we look back at the search that we ran at the beginning of this post, we see that there was another record in the search result image and clicking on the “Details” tab for that record shows that it is from CUNY Academic Works:
Click in the full screen view URL/address box and add “&showPnx=true,” just as you did earlier. This will take you to this record’s PNX record and there you will be able to see the sourceid and sourcerecordid, just as we did for the Aleph record.
<sourcerecordid>jj_pubs-1019</sourcerecordid>
<sourceid>CUNY_BEPRESS</sourceid>
<recordid>CUNY_BEPRESSjj_pubs-1019</recordid>
(bepress is the vendor of the CUNY Academic Works software.)
To view Academic Works source data, we need a different (and longer) base URL:
http://academicworks.cuny.edu/do/oai/?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:academicworks.cuny.edu:
Otherwise, the process is the same. Take the sourcerecordid from the PNX record and add it at the end of the base URL. For example:
That was a lot for one post. But we have tools to make it easier: bookmarklets!
Coming soon:
