[OPEN-ILS-DEV] URI scoping in Evergreen

[Rogan Hamby]

I'm not going to intrude on the direct exchange between Mike and Liam about
the scoping though I'm very interested in the conversation.

I'm also very interested in the potential impacts of
opac.ou_ignore_luri_as_copy
and opac.include_all_pref_ou_uris .

We have the situation of having a State Library as a member of the public
library consortium.  They have bought access to a very large number of
ebooks on academic topics.  Because of their licensing anyone using our
catalog can potentially get access to these books by getting a state
library card, or can access them via a staff member at their local library
who may have one.  They bulk uploaded these records and were the first
heavy user of the 856$9 use in SCLENDS.

This created an interesting searching issue before the located URIs really
got straightened out but it brought out a lot of discussions about
reference services related to searching.  The core issue was with search
results being flooded with electronic results which isn't what people were
expecting.  Although our state library issue may be unusual I can imagine
similar scenarios that could be a lot more common with public domain
materials, state wide databases, etc....

Ideally, we would like to be able to define a default by an org unit to
include or not include electronic holdings but actually able to override is
on a search by search basis in the TPAC.




On Tue, Jul 15, 2014 at 4:59 PM, Liam Whalen <liam.whalen at bc.libraries.coop>
wrote:

> 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
> liam.whalen at bc.libraries.coop
>
>


-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

“You don't have to burn books to destroy a culture. Just get people to stop
reading them.”
― Ray Bradbury <https://www.goodreads.com/author/show/1630.Ray_Bradbury>

“You can never get a cup of tea large enough or a book long enough to suit
me.”
― C.S. Lewis <http://www.goodreads.com/author/show/1069006.C_S_Lewis>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140716/3fec05ae/attachment-0001.htm>