-
Notifications
You must be signed in to change notification settings - Fork 3
URL Fields
We are separating two or three kinds of URLs (856u
) for display/use in records: fulltext, version or partial, and supplemental URLs. When coded correctly, URLs can be identified by the following factors. Updated 6/18/19 to change ordering so that we can include 4*
as a backup if not *1 or *2.
NOT_FULLTEXT Flag: Sometimes links coded in ways that you might think are full text actually contain language in their opening z
or 3
which indicate that they're not actually fulltext. Words to look for are: addendum, appendices, appendix, appendixes, cover, excerpt, executive summary, index
. We've made this as NOT_FULLTEXT
856 indicator | type of link | single record label | results label |
---|---|---|---|
*1 OR (*0 AND NOT_FULLTEXT ) |
Version/Partial - version of the resource.) | Online Version | not displayed |
*2 |
Supplemental | Related Resources | not displayed |
(*0 OR *<blank> OR ** ) AND !NOT_FULLTEXT |
Fulltext | Access Online | Access Online |
*1 AND subfield y == IIIF manifest
|
IIIF manifest | don't display, we need to index the 856u only into a field that'll be used for the viewer | don't display |
As part of the IIIF project, we'll be indexing IIIF manifest URLs separately from links we display. These will be used only for the IIIF viewer, not displayed elsewhere in the record.
To begin with, these can be identified by being 856|41
where the subfield y == IIIF manifest
.* We'll only need to index 856u from these fields. They are not likely to repeat, but may.
* We may also be able to identify them through ARK syntax once we've updated them with ARKs. Unlike the finding aids below, we'll still want them in their own fields because a) we're not displaying them, b) we only need 856u.
Special Collections finding aids index as "Related resources." This is not wrong, but we want to separate them out for display which clearly indicates that they're a way to find more materials in our special collections and not just any old related resource. These URLs can be identified as containing ark:/42409/fa8
. (handled in https://github.com/psu-libraries/psulib_blacklight/issues/1007)
In our MVP, we used the domain as the link text. As we enhance online access display, we'll add display of link labels and notes.
While best practice would have only one u
, one y
, one z
, and one 3
, only 3
is non-repeatable. This means a record could, in theory, have more than one link, text, or description. In theory, repetition should be done in sets. If it contains more than 1 set, these should be done as pairs following each u
, e.g. |u |y |z |u |z
etc.
Recommend handling these as an array (or as an array if more than 1 exists -- but a straight-up array might avoid more testing) and pairing link[0] with label[0] and description[0], link[1] with label[1] and description[1], etc. Is there a way to account for sets?
Poor data entry could mean that link[1] should go with label[0] and description[0] but if we receive reports of these, we will pass on the entry to cataloging to split out the 856 fields.
MARC field | use for | description |
---|---|---|
8563 | link context | text to display before link |
856y | link label | text intended for use as a label |
856z | link note | text intended for additional context about the link |
All subfields are optional and a field may contain either or both. Both y
and z
MAY repeat. For 856z, we can simply concatenate any repeated fields with a space. For 856y, we should only use one value.
Field order if all three exist, see logic below for if label/note don't exist:
3: <a href="u">y</a>, z
If the 856 contains a 3
(and it can only contain 1), display it before the link, followed by a colon and space. Otherwise do not prefix the link..
The following four possibilities are based on whether there's a link label and/or a link note.
- No link label, no link note: use MVP default of displaying the domain.
- Link label, no link note: use link label.
- No link label, link note: use MVP default of displaying the domain, followed by the link note.
- Link label, link note: use link label as label for link, follow with link note.
- Home
- Testing Documentation for Product Owner
- Components, Features, and Functions
- Library Faceting and Locations Management
- Advanced Search
- Browse Items By Library of Congress Call Number
- Browse by Subject, Author, and Title
- Availability Display
- Summary Holdings Display
- Holdings and Availability for Bound-Withs
- Holds and ILL
- Requesting Items with Aeon
- Course Reserves
- Google Books and HathiTrust Integration
- Bento Integration
- Indexing and Display
- Sources of Catalog Data
- Display Fields
- Title Fields
- Author and Creator Fields
- Thesis Department
- ISSNs and ISBNs
- URL Fields
- Publication and Edition Fields
- Material Characteristics Fields
- Language Fields
- Subject Fields
- Genre Fields
- Note Fields
- Serials
- Bound-Withs
- Formats
- Media Types
- Access Facet
- Open Access Facet
- Call Numbers
- OCLC Number
- LCCN
- Report Numbers
- Endowment Codes and Names
- Adding Linked to Request Scanning
- Summary Holdings Indexing
- My Account
- Tests
- Development Setup and Notes
- Deployment Notes