Using the new global setting opac.luri_as_copy, which treats URIs as copies, is
working well for Sitka, but our libraries need more granularity regarding which
URIs get displayed. Currently, when visiting a record with URIs attached we
are getting too many URIs appearing in the record details. In some cases over
50 URIs are being displayed. In cases where one record contains unique links
for each library, this is not a desirable situation for patrons because they
have to hunt through the links to find the correct one for their library.
We have code now that allows us to select URIs based on the OU supplied in 856
$9, but we need further specificity regarding which OUs display which URIs.
Here is an example of our OU tree:
Sitka
/ \
Federation Federation
/ \ / \
System System System System
/ \ / \ /
\
Library Sub-System Library Library Library
Sub-System
/
Library
/ \
Library Library
In some instances, a system will have its OU as the 856 $9 value. But,
searches at the Sub-system or Library level underneath the System, will need to
display that URI from the System. In other cases, searches at the System level
will need to display URIs owned at the Library or Sub-System levels.
I am proposing 2 new OU settings, opac.uri_ancestor_scope and
opac.uri_descendent_scope. These would be numerical values letting the TPAC
know how far up or down the OU tree the TPAC needs to search in order to find
URIs for a give OU. In most cases, these settings will need to be set for every
OU because setting inheritance will not make sense most of the time.
These changes will also require two new TPAC function that can retrieve n
number of OU ancestors and n number of OU descendants, so the 856 $9 can be
properly checked. Does something like this already exist?
Additionally, I am proposing another setting opac.ou_ignore_luri_as_copy. For
Sitka’s purposes, this is set at the 1st and 2nd level OUs, so that URIs are
not displayed in the search results for those OUs. If URIs were displayed at
our 1st and 2nd levels the search results pages would be too big to be useable.
Finally, when including URIs as copies, Sitka libraries only want records
belonging to the pref_ou to be included in the search results if the pref_ou is
within the OU tree for the search OU. I have code for this working now, and it
is only a slight modification, but I am not sure if that fits with everyone’s
needs, so it might require a library setting as well. Something like
opac.include_all_pref_ou_uris might work.
What does the community think of this plan? Are there any situations where
this is unhelpful to consortia as they exist now? I believe e-resources are a
growing part of library systems, and I do not want to diverge from the
community code. At the same time, Sitka libraries need these changes. So, if
we can come to an agreement on how to best display 856 values, I will make it
happen.
Liam Whalen
BC Libraries Cooperative - Sitka
Systems Specialist
855-383-5761 x1022
[email protected]
