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 https://github.com/sul-dlss/purl/issues/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.

[andrewjbtw]

If this is a purl problem, should there be an issue for purl to handle the ID the same way for collections as for items? It sounds like that would make the URLs for the collection links consistently work without a prefix.

That said, leaving SDR aside, I think ideally the URL should work with the prefix, since that is the real identifier in FOLIO. I understand making the unprefixed identifier work for backwards compatibility, but I think someone with no knowledge of Symphony should reasonably expect to be able to use the FOLIO identifier in SearchWorks.

That is, since these two URLs both resolve:

• https://searchworks.stanford.edu/view/10357851
• https://searchworks.stanford.edu/view/a10357851

I would also expect that both of these URLs would also return results:

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

It sounds like once we fix this issue, only the URL without the prefix will work.

[saseestone]

Using https://purl.stanford.edu/ct961sj2730, this still looks broken.

[dnoneill]

I am not sure this is actually still broken. Searchworks updates haven't been deploying to prod for at least two weeks.

[saseestone]

Thanks @dnoneill! I wrote the comment just as we discovered that deploy's to prod were plugged up. All looks much better now.

@andrewjbtw collections links are working now.