(A similar problem, with another cause https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/41985421-possibility-to-disactivate-related-link-to-physica )

Another example of how this problem messes up our catalog:

Publication format = Bilderbuch
https://basel.swisscovery.org/discovery/search?query=genre,contains,Bilderbuch,AND&tab=UBS&search_scope=UBS&vid=41SLSP_UBS:live&mfacet=genre,include,Bilderbuch,1&lang=en&mode=advanced&offset=0

I only want to see the ones from a particular library ->
https://basel.swisscovery.org/discovery/search?query=genre,contains,Bilderbuch,AND&tab=UBS&search_scope=UBS&vid=41SLSP_UBS:live&facet=library,include,5504%E2%80%93112070590005504&mfacet=genre,include,Bilderbuch,1&lang=en&mode=advanced&offset=0

But I get titles that UB Hauptbibliothek doesn't have, for example
https://basel.swisscovery.org/discovery/fulldisplay?docid=alma9948041300105504&context=L&vid=41SLSP_UBS:live&lang=en&search_scope=UBS&adaptor=Local%20Search%20Engine&tab=UBS&query=genre,contains,Bilderbuch,AND&facet=library,include,5504%E2%80%93112070590005504&mode=advanced&offset=0

Dear Yael,
Here comes an attachement in order to show the problems we have at Uppsala university.
Best regards
Bodil Wik

Dear Yael,
I tried to document in the attached file some examples and use cases that would positively be impacted by this enhancement in my opinion.
Kind regards
Fabiano

> In which cases the relation is correct

Dear Yael

For the display and functions of Fulfillment / Getit and facets in Primo, only this example is correct

https://basel.swisscovery.org/discovery/fulldisplay?vid=41SLSP_UBS:live&search_scope=UBS&tab=UBS&docid=alma9964782120105504&lang=en&context=L

it has a MARC field 773 $w

773 0#$tPro Natura lokal Basel $g2015, Nr. 4, 31 S. $q2015/4/31 $gyr:2015 $gno:2015 $w(IDSBB)001400350DSV01

----

All the other relations should only be visible under Details in the full record display. There they can be a link which leads to the other bib record, but no other function should be generated.

Hi all,
In order to better understand the requirements here -
today the relation is used in Alma resource management, in Fulfillment calculations and also in the Primo GetIt and facets.
We would like to ask you where do you see this change impact and under which conditions. We would appreciate any examples and use cases. In which cases the relation is correct, and in which it doesn't.

Thank you,
Yael.

https://basel.swisscovery.org/discovery/fulldisplay?vid=41SLSP_UBS:live&search_scope=UBS&tab=UBS&docid=alma9972649195905504&lang=en&context=L

Basel - UB Hauptbibliothek has this title.

'Show more locations' shows me
Basel - Uni Geschichte

who do NOT have this title.

-----

https://basel.swisscovery.org/discovery/fulldisplay?docid=alma997632760105504&context=L&vid=41SLSP_UBS:live&lang=en&search_scope=UBS&adaptor=Local%20Search%20Engine&tab=UBS&query=any,contains,3518574701&sortby=date_d&facet=frbrgroupid,include,9082493689607880698&offset=0

"Available at ... and other locations"

This is not true. Only "Basel - Uni Philosophie" has it.

---

This is the only case where we want to show "Locations for related titles":

https://basel.swisscovery.org/discovery/fulldisplay?vid=41SLSP_UBS:live&search_scope=UBS&tab=UBS&docid=alma9964782120105504&lang=en&context=L

773 0#$tPro Natura lokal Basel $g2015, Nr. 4, 31 S. $q2015/4/31 $gyr:2015 $gno:2015 $w(IDSBB)001400350DSV01

Dear Yael

This is great to hear, thank you.

NERS 8781, open for voting now.

Please vote to make our catalog less frustrating for our patrons.

Would be an important improvement!

Uppsala university also strongly supports this request. When relations for 830 $x generates related items in Primo, it gets very difficult for users to request the right material. There is no way to stop another item from the same series to be requested instead of the item bound with the item the user wants.

NERS 8161, round 2 open for voting now.

Please vote if you can, this would fix sevaral problems.

As stated earlier:
As long as this is not fixed, Primo VE just looks broken/unreliable for our patrons.

NERS 8161, open for voting now.

For the next round of voting the NERS ID is 8161

This also leads to wrong information being shown to the patrons.

https://basel.swisscovery.org/discovery/search?query=any,contains,%22alice%20keller%22&tab=UBS&search_scope=UBS&sortby=date_d&vid=41SLSP_UBS:live&facet=frbrgroupid,include,9041446181354293754&lang=en&offset=0

'Available at ... and other locations'.

No, only one library in our IZ has the printed version.

This teaches our patrons that they can't trust what they see in our catalog.

NERS 7857, open for voting now

Part of this is a bug fix, not a feature request:
When I turn off 'Display related holdings for monographs', the library facet should behave accordingly and NOT show libraries that stem from the 'related holdings' part.

I even think that this is how the library facet should behave when 'Display related holdings for monographs' is turned on: the facets need to filter my short title list. I do not want to see a library facet because that library has OTHER titles.

We strongly support a more nuanced treatment of records with a 773 field and the effect it has on related records.

In addition to what you write in the idea, we've struggled with the fact that the system doesn't take the second indicator into account either. A 773 second indicator can either be # or 8. # represents "In", which indicates that the record is a part of the Host Item, while an 8 does not. When this is not taken into account, it causes trouble with holdings information. Our suggestion would be that a change to this behavior is considered within the scope of this idea as well.

> When filtering to a certain location via facets, you often get results from other locations too

As long as this is not fixed, Primo VE just looks broken/unreliable for our patrons:
I filter by a certain library, but the short title list includes titles that are NOT in that library.

I agree with Luzern, absolutely a must-have! You dont find the books you know are in the library because you dont expect this false behaviour.