Handling Serials Holding Edge Cases - Entries Not Displaying
Closed this issue · 4 comments
Since our last work on the Catalog, we've had two edge cases surface for serials holdings. For both of these, I'm sure we have more that either haven't been noticed (because they weren't what the person was looking for in the record) or that are in records that haven't been visited since we launched it. The issue is that more than one holdings statement per Library:Location pair isn't displaying in the Availability/Summary section.
Research note: It turns out we're indexing these properly! So they just need to be displayed. Currently we are only displaying item 0!
{
"UP-ANNEX": {
"ANNEX": [
{
"call_number": "TN823.P4 M3",
"summary": [
"1952, 1957, 1962"
],
"supplement": [],
"index": []
},
{
"call_number": "338.272 An86m",
"summary": [
"1948, 1953, 1955, 1958, 1960"
],
"supplement": [],
"index": []
}
]
}
}
Outcomes
One possible method would be doing it like this:
Library Storage
Annexed Material
TN823.P4 M3:
1952, 1957, 1962
supplement 1
338.272 An86m:
1948, 1953, 1955, 1958, 1960
index 1960
Or to take up a little less space:
Library Storage
Annexed Material
TN823.P4 M3: 1952, 1957, 1962
supplement 1
338.272 An86m: 1948, 1953, 1955, 1958, 1960
index 1960
AND we could decide to only display call numbers if len(list) > 1.
Sample records
(check MARC view, /raw.json, and display for discrepancies)
- Location is same, but call # is different (Dewey vs. LC): https://catalog.libraries.psu.edu/catalog/126670
- Everything except |i ("Item part") repeats - we haven't been displaying because this generally isn't useful data, but might we need to index it in order to have it not seem like a duplicate? https://catalog.libraries.psu.edu/catalog/3865799
This is partly research, I think -- what would be necessary to sure that the missing entry displays?
If you want some catkeys: https://github.com/psu-libraries/psulib_blacklight/wiki/Holdings-Indexing
I'd see what's in their /raw.json to be sure
@ruthtillman I've got the call number/summary part taken care of, but the way things are set up, there's a scenario that's concerning me with supplement/index: there's multiple holdings statements for a single library:location pair and each statement has supplement/index data.
Example:
{
"UP-ANNEX": {
"ANNEX": [
{
"call_number": "TN823.P4 M3",
"summary": [
"1952, 1957, 1962"
],
"supplement": [supplement1],
"index": [index1]
},
{
"call_number": "338.272 An86m",
"summary": [
"1948, 1953, 1955, 1958, 1960"
],
"supplement": [supplement2],
"index": [index2]
}
]
}
}
The way to code is currently written, only supplement1 and index1 would be displayed. So questions are:
- Is this even possible? I've looked at the raw json for all of the holdings indexing examples & our dev data and haven't found it, but I know that doesn't necessarily mean it doesn't exist.
- If it is possible, is it an edge of an edge case/do we need to be concerned about it?
With serials, unfortunately, all things are possible. So it's something we should address. (and having worked with them for over 5 years, it's not unlikely, just not common enough to easily find.)
Looks great!