[OPEN-ILS-DEV] URI scoping in Evergreen
Liam Whalen
liam.whalen at bc.libraries.coop
Mon Aug 4 13:26:14 EDT 2014
On Aug 4, 2014, at 7:29 AM, Mike Rylander <mrylander at gmail.com> wrote:
>
> On Tue, Jul 29, 2014 at 2:13 PM, Liam Whalen <liam.whalen at bc.libraries.coop> wrote:
> On Jul 16, 2014, at 5:42 AM, Mike Rylander <mrylander at gmail.com> wrote:
>
>> On Tue, Jul 15, 2014 at 6:17 PM, Liam Whalen
>> <liam.whalen at bc.libraries.coop> wrote:…
>
> I need to take a look at the code before I could respond again. My apologies for the delay.
>
>
> No problem. It's dense code, plenty to reason about.
>
>
>> However, I think I just had a "eureka!" moment ... please try to clear
>> your mind of any implementation thoughts, and bear with me for a
>> minute:
>>
>> ==========
>>
>> First of all, let's separate visibility testing from the display of
>> LURIs in any given context. I'll start with visibility testing.
>>
>> Starting from first principles, LURIs are meant to act in a way that
>> models access rights. If you search at location X (or your pref_ou is
>> X), and an LURI is owned by X or one of its ancestors, then you are
>> said to be within the "access rights range" of the LURI. Therefore
>> the record is included in results, and the LURI is available for
>> display wherever the record is shown (detail or otherwise). This does
>> not mean the LURI /must/ be shown, just that it is available to be
>> shown. The TPAC today does show LURIs everywhere, of course.
>>
>> We have, in 2.6, the ability to expand the "access rights range" of
>> LURIs so that, when calculated during search, if an LURI is owned by a
>> /descendant/ of the search/pref_ou location then you are said to be
>> within the "access rights range". This is accomplished by turning on
>> the "LURIs as copies" setting. Stated more simply, the effect of the
>> new settings is to extend the descendant side of the range we use for
>> visibility testing.
>>
>> Now, what you are proposing is /not/ a modification to the "LURIs as
>> copies" behavior at all. Instead, you are asking for a way to change
>> to how the core, unadjusted "access rights range" is calculated.
>> Specifically, you want the search context org (that is, both the
>> selected search location and the pref OU) to influence the ancestor
>> side of the "access rights range". This is entirely reasonable. And,
>> it can be done with exactly one new YAOUS (inheritable), and just a
>> few lines of code in the search stored procedure that gathers the
>> LURI visibility testing array. Let's call this YAOUS
>> "opac.luri_ancestor_visibility_depth".
>>
>> The YAOUS would contain an OU Type Depth (0 for SITKA, 1 for
>> Federation, etc). If not NULL for the OU in question (context or
>> pref_ou, each), this value is passed as the second parameter to
>> actor.org_unit_full_path, or actor.org_unit_simple_path (which would
>> replace the call to actor.org_unit_ancestors) if "LURIs as copies" is
>> not enabled. This would not change any of the "LURIs as copies" logic,
>> but be a peer adjustment that adjusts the ancestor side of the range
>> used by all LURI visibility testing code.
>>
>> Now, how to decide when and where to show LURIs. This could be done
>> simply with a YAOUS -- call it "opac.luri_result_display.context" --
>> which indicates that no LURIs should be displayed on the result page
>> when the YAOUS owner (or inheritor) is the search context org. A
>> second YAOUS -- call it "opac.luri_result_display" -- could be used to
>> control whether LURIs owned by the YAOUS owner/ineritor are /ever/
>> displayed on the result page, even when the search context has the
>> "display LURIs on the result page" set to true. The TPAC would
>> inspect these settings for the search context OU and the LURI owners
>> when rendering the result page.
>>
>> The list of LURIs to make available for display will require only a
>> minor adjustment to the unAPI-related code that gathers LURIs for a
>> given search, but that will basically mirror the visibility testing
>> change described above, making use of the
>> "opac.luri_ancestor_visibility_depth" YAOUS. Everything else
>> display-related can remain blissfully unaware of the changes here.
>>
>
> I think I can replace the two settings (opac.luri_result_display.context and opac.luri_result_display) with a second setting similar to opac.luri_ancestor_visiblity_depth. This setting would be opac.luri_descendant_visiblity_depth.
>
>
> Well, the two separate ones I propose were for deciding on the display in two interfaces: result list, and record detail. If we don't need to control those individually, then one is fine. But IMO it should be an on/off switch, and let the unapi logic decide what data is available for display.
Sitka does have a difference between the result list and the record details page. We cap the number of links shown on the record details page to 5. So, there should be another setting opac.luri_results_max to limit how many URIs are returned by unapi (this would be a LIMIT value).
>
> The case where we want to disable URIs from being displayed is at the Sitka level (depth 0). In this case, opac.luri_descendant_visiblity_depth would be 0 and opac.luri_ancestor_visiblity_depth would be 0. In our case, this would prevent any URIs from being displayed at depth 0 searches. And other libraries that do wish to have URIs displayed at depth 0 can set the two settings appropriately.
>
> At the Federation level (depth 1). The ancestor_visbility_depth would be 1, and the descendant_visiblity_depth would be 4 (our lowest setting). I am considering using a -1 value to indicate maximum descendant_visiblity_depth, but I am not sure if this is a good idea because it might have unexpected results when a new depth is added to the OU types.
>
>
> I'm pretty strongly against using -1 as a magic number for a couple reasons: First, using a suitably large number (say, 100) has no effect on the performance of the stored proc, because it basically stops when it gets to the leaves of the tree, and a large value is more clear to later developers than a magic number. Second, there is code already that uses a negative depth value to indicate a switch from org units to org lassos. While that code may not interact with this code today (and I'm not sure it /doesn't/), I'm not sure about the future.
>
That makes sense. I will not use -1.
> At the System level (depth 2), the ancestor_vislibity_depth would be 2 and the descendant_visiblity_depth would be 4 or -1 (if we decide to use -1 as maximum depth). From here, all the other OUs would inherit settings in our case.
>
> Then in the unapi code the evergreen.located_uris code would pass both ancsetor_visiblity_depth and descendant_visibility_depth to actor.get_full_path or actor.get_simple_path depending on the opac.located_uri.act_as_copy setting within a WHERE clause to limit the URIs returned via unapi. This would happen once for the search OU and once for the pref OU.
>
>
> Well, pass or look up. My preference would be to look it up where it's needed instead of passing it everywhere.
>
Ok, I will look it up instead of passing it.
> This results in only the necessary URIs being returned to TPAC, which should simplify that code greatly.
>
>
> Other than my comments above, it sounds like we're basically on the same page WRT implementation. Awesome! Are you planning to look at implementing this soon? If so, I'll await that and happily review as soon as I can.
>
I am. Currently, I am working on changes to the ACQ rollover code for 2.next. When that is finished, I will start this work.
Liam
> --miker
>
> Liam
>
>> ==========
>>
>> Please shoot any holes in this that you can! I'm pretty sure that
>> this covers your desired outcome.
>>
>>
>>> This is further complicated by records with both copies and URIs attached. In these cases, copies should override the URI rules as far as search results go. So, if a record with both copies and URIs would be excluded because the URI is not within the fenced off area, but there is a relevant physical copy, then the record should be displayed in the search results.
>>>
>>
>> Let's set aside the notion of "exclusion" ... we're not (and should
>> not start) actively excluding record based on a positive test, we are
>> passively including when in-range visibility tests find a triggering,
>> attached "thing" (item/LURI/transcendent source/etc). What we want to
>> do is find the way to adjust the definition of "range" so that it
>> covers what we want, and the existing logic does the rest.
>>
>>>>
>>>> The answers to those will help me comment intelligently.
>>>
>>> Thank you for taking the time!
>>>
>>>> As to the question about pref_ous, the current behavior was
>>>> specifically requested as a feature, so I think it would be a mistake
>>>> to remove that as the default. If I look at SITKA as a group of
>>>> separate consortia sharing one system and co-cataloging bibs, I can
>>>> certainly see where you're coming from here, though. I believe
>>>> something can be worked out.
>>>>
>>>
>>> I think a setting can be checked within query_parser_fts without too much overhead. Although, I have not done any EXPLAIN ANALYZE between my modified query_parser_fts and the current master query_parser_fts. It gets called often enough, that even a small change would be detrimental in the long term. query_parser_fts has a lot of input parameters, and I am not sure if I will be able to construct one to use with EXPLAIN ANALYZE, but I will try and get some metrics to help inform the discussion.
>>>
>>
>> IME, the lookup of YAOUS values is so extremely cheap compared to the
>> cost of the core query that until we start adding 10s of them we can
>> ignore the cost for the moment. And there are techniques for
>> addressing the speed of that if it ever becomes noticeable.
>>
>> --Mike
>>
>>>> Thanks, Liam!
>>>>
>>>> --
>>>> Mike Rylander
>>>> | Director of Research and Development
>>>> | Equinox Software, Inc. / Your Library's Guide to Open Source
>>>> | phone: 1-877-OPEN-ILS (673-6457)
>>>> | email: miker at esilibrary.com
>>>> | web: http://www.esilibrary.com
>>>>
>>>> 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
>>>>>
>>>
>>
>>
>>
>> --
>> Mike Rylander
>> | Director of Research and Development
>> | Equinox Software, Inc. / Your Library's Guide to Open Source
>> | phone: 1-877-OPEN-ILS (673-6457)
>> | email: miker at esilibrary.com
>> | web: http://www.esilibrary.com
>
>
>
>
> --
> Mike Rylander
> | Director of Research and Development
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker at esilibrary.com
> | web: http://www.esilibrary.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140804/93850d11/attachment-0001.htm>
More information about the Open-ils-dev
mailing list