Link to view items in collection is broken due to FOLIO hrid prefixes

[thatbudakguy]

This is evident with the Batchelor Map Collection (https://purl.stanford.edu/ct961sj2730):

• The "view in searchworks" link https://searchworks.stanford.edu/view/10357851 goes to the collection (correctly)
• The "view items in this collection in searchworks" link goes to https://searchworks.stanford.edu/catalog?f[collection][]=a10357851, which does not resolve to any items

The latter link seems to be using the prefixed version of the HRID (it starts with an a).

See also sul-dlss/purl#797

[andrewjbtw]

However, the link in the Roy Pryor collection record does work: https://purl.stanford.edu/ht919ys1747

• View items in this collection has the prefix: https://searchworks.stanford.edu/catalog?f[collection][]=a7514188

Unless I'm missing something, it looks to me like SW may be indexing post-migration FOLIO records differently than pre-migration records. The Roy Pryor collection was created post-migration.

See also:

• https://purl.stanford.edu/vf855pq5091
• https://purl.stanford.edu/cg895tj6980

and presumably a number of other examples of released collections with folio HRIDs that were created post-FOLIO migration

[andrewjbtw]

There also appear to be cases where SW returns items in the collection only if the prefix is present.

Bay Area video arcades : photographs by Ira Nowinski, 1981-1982: https://purl.stanford.edu/sk882gx0113

• View items in this collection in SearchWorks: https://searchworks.stanford.edu/catalog?f[collection][]=a9685083

That returns results, but removing the prefix leads to no results:

• No prefix: https://searchworks.stanford.edu/catalog?f[collection][]=9685083

I found this example in a Slack thread from fall 2023, which is when we implemented the link.

It seems like the expectation back then was that SW would return results when including the prefix. But SW doesn't seem to be consistent one way or the other.

[thatbudakguy]

hmm – maybe this is a problem on the SW side, then?

[thatbudakguy]

moving this ticket to SW; maybe we can look at it during upcoming workcycle.

[cbeer]

Isn't this a PURL problem? There's logic here to handle the catalog ids: https://github.com/sul-dlss/purl/blob/04df4215f02e6731a38aeb6ef785d32dfc03aacf/app/models/public_xml.rb#L20

but that's not used for collection ids:
https://github.com/sul-dlss/purl/blob/main/app/models/public_xml.rb#L30

[andrewjbtw]

See the examples above: sometimes SW returns results only with the prefix, sometimes only without the prefix.

Only with the prefix:

• https://searchworks.stanford.edu/catalog?f[collection][]=7514188 (no results)
• https://searchworks.stanford.edu/catalog?f[collection][]=a7514188 (results)

Only without the prefix:

• https://searchworks.stanford.edu/catalog?f[collection][]=10357851 (results)
• https://searchworks.stanford.edu/catalog?f[collection][]=a10357851 (no results)

Whichever logic purl should follow, one or the other case will fail for some collections.

[corylown]

The difference between "only works with prefix" and "only without the prefix" is that the items in the collection are in the former case SDR records and in the latter case they are FOLIO records.

So, I think Chris is right that this is purl problem.