search

pulibrary / orangelight

PUL Blacklight Project (Ruby 3.1.0, Rails 7.1.4)
21 stars 7 forks source link

Handle cases where multiple bib. IDs are linked to the same ARK (possible sammelbands) #1532

Open jrgriffiniii opened 5 years ago

jrgriffiniii commented 5 years ago

https://catalog.princeton.edu/catalog/4782614 does not resolve a viewer, but > https://catalog.princeton.edu/catalog/4782613 does. https://catalog.princeton.edu/catalog/4782614 points towards an ARK which specifies 4782613 as the bib. ID:

...
electronic_access_1display: "{"https://catalog.princeton.edu/catalog/4782613#view":["Digital content"],"iiif_manifest_paths":{"http://arks.princeton.edu/ark:/88435/z316q164g":"https://figgy.princeton.edu/concern/scanned_resources/f9d5e7af-fac4-408e-8d5f-49fe3f5c026f/manifest"}}",
...

where http://arks.princeton.edu/ark:/88435/z316q164g redirects to > https://catalog.princeton.edu/catalog/4782613#view

Please see https://github.com/pulibrary/orangelight/issues/1531#issuecomment-450885486 for the context of this.

tpendragon commented 5 years ago

From @joycebcat

It looks like James closed this ticket and another that it pointed to before I got to this today. What is going on with these records is a common occurrence with manuscript compilation volumes. There is a bib record for the volume as a whole – in this case 4782613 – and then also separate records for the titles within the volumes. In this case there are three records (see below) all of which also have this same ARK in the catalog record.

4782617 4782618 4782614

Only the composite record shows the digital viewer. I don’t understand why the catalog data on the other records doesn’t also generate the viewer for those displays. Are you using something other than 856 data from the catalog record now to embed the viewer?

The result here is that users who find a specific title have to click through to the “contained in” link, or click on the “digital content” link in the holdings section. Possibly not the end of the world, but not necessarily understandably consistent behavior from the user’s point of view.

tpendragon commented 5 years ago

So this is the one edge case we hoped didn't exist, basically. Right now Orangelight sends a query for all records which have the bib-id that the user is currently on, and Figgy returns any digital records that match.

In this case there are three bib-ids for one record in Figgy.

Solution Options:

  1. ALSO key off the 856 field in the catalog
  2. Allow users to input "alternate bib-ids" in as part of the digital record, then adjust the query so it returns any records which have that ID in the alternate field too.
  3. Just don't fix it.
joycebcat commented 5 years ago

There is another situation which is broken by your new method. We have multiple digital objects related to a single bib record. https://catalog.princeton.edu/catalog/2274590 is one example. We have two copies of this object, both digitized. We used to have both embedded viewers at the bottom of the bib record, now there are neither but there are links in the "online" availability section. We have several examples of this situation.

tpendragon commented 5 years ago

@joycebcat That particular one doesn't render because those items aren't marked complete. That being said, we do have a bug with loading multiple viewers, but I think the plan is to fix that with the show page refactor.

Edit: In case it wasn't clear - our current method supports one bib-id having multiple items in Figgy.

christinach commented 5 months ago

See the result at this report. Reevaluate this .

christinach commented 3 weeks ago

we need to find examples in order to evaluate this ticket