[OPEN-ILS-DEV] URI scoping in Evergreen
Mike Rylander
mrylander at gmail.com
Wed Jul 16 08:42:42 EDT 2014
On Tue, Jul 15, 2014 at 6:17 PM, Liam Whalen
<liam.whalen at bc.libraries.coop> wrote:
>
> On Jul 15, 2014, at 2:49 PM, Mike Rylander <mrylander at gmail.com> wrote:
>
>> I need to think about this much harder than I have (which is not hard
>> at this point...), but I have some questions to start with before
>> commenting on the specific plan you've outlined.
>>
>> * Is this primarily about display of LURIs on the record detail page,
>> or is it actually about inclusion of records in the result list? Or,
>> both (it's not entirely clear if there are multiple "issues"
>> addressed)?
>
> This is about both the records detail page and the result list. The opac.ou_ignore_luri_as_copy is only about the result list though, it is there to manage too much information in the result list.
>
>> * Are there cases where it would be useful to set an LURI-specific
>> scope? (perhaps, but not necessarily, a scope (range) encoded with the
>> owner in the $9 of the 856)
>
> That may make more sense to come at it from that perspective. I had not considered that. It does mean more work for cataloguers, but it would mean less settings and most likely less complicated code.
>
Ahh, but I'm confident we can make it so that it's no more work than
today in the common case, and more useful/flexible when it needs to
be! First, though, I need to understand better both the problem and
the desired (functional, not implementation) outcomes, which is the
driver for my questions. Please don't assume I'm against any
particular implementation -- I just want to start the discussion with
the goals outside any implementation context.
>
>> * Related to the previous question, could the outcome of what you
>> outline be described in terms of a default value to use when the LURI
>> does not supply a scope?
>
> I can make these changes work in Sitka’s context without settings, but I am not sure it would apply to all contexts. For instance, if an OU has a depth of 2, and it has a child OU, which also has a child OU, then I know it is a System, with a sub-system, and a library underneath it. At the same time, if I know an OU has 4 ancestors then I know it is a library with a sub-system, a system, a federation, and Sitka above it. What I am not sure about is how generic our OU tree is in regards to library systems in general. Which, is why I was suggesting the settings, but I like the idea of encoding the scope within the 856 more than all the settings.
>
To be clear, I'm not prescribing a solution in these questions. Here,
in particular, I'm performing a thought experiment to help reset any
assumptions I'm making. What I'd like to do is examine the goals and
then consider solutions, but the context I have so far is essentially
a solution without a well-detailed goal. That might certainly just be
me not fully groking your use cases.
>> * Am I correct that the effective use-case here is to create sections
>> of the org tree that are fenced off from one another WRT URI
>> visibility?
>
> That is correct.
>
Cool. To refine my question a bit more, you write further down about
the different levels, and reasoning out the interpretation of an LURI
based on relative depths and distances. But, based on this answer,
and the way you talk about the effective differences between levels of
the hierarchy later, ISTM that the LURI-owning OU Type itself would
tell us more about the desired visibility boundaries than anything we
might be able to infer from the depth of the owner or the depth below
it. Does inspecting the OU Type (or the type's depth) directly seem a
reasonable replacement to attempting to reason visibility based on the
ancestor/descendant distance?
As an example, perhaps those owned at a System should be visible
within the System's Federation and when searching peer Systems but
/not/ Branches below peer Systems, but those owned at a Branch should
only be visible when searching the System or peer Branches. (Not that
I got that correct from a configuration point of view, mind you, but
as an example.)
>> * If yes to the previous question, would this extend to copy visibility?
>
> No, this is strictly for URIs. I believe, because copies are physical, they are much more naturally assigned to the OUs that need to have control of them. URIs, in Sitka’s case, may be assigned at various levels depending on how a library or system needs to conceptual organize ownership.
>
Good, that simplifies things.
>> * If no to /that/ (and related to the first question), would you
>> still want the records found, just with a truncated or otherwise
>> altered LURI display?
>
I'll try to restate these, to make sure I understand the point.
> In the case of a top level search, we would like all relevant records to be displayed, with no links show in the search results. But, links displayed in the record.
>
So, this is "today's behavior" plus "list is to big, just display on
record details page";
> In the case of a 2nd level search, we would like all records within the 2nd level’s tree displayed with no links in the search results. But, links displayed in the record.
>
This is more complicated ... it's effectively "ignore SITKA-owned
LURIs" (which is new behavior) plus "list is to big, just display on
record details page"
> In all other cases, if the URI would not be displayed for the search or pref OU, then the record should not be displayed.
>
I'm not sure I follow this one. The decision of whether to include a
record on not has been modified by the first two above, so "in all
other cases" is unclear to me.
That said, I think the goals boil down to two items:
1) Only include records with SITKA-owned LURIs if the user searches
at the SITKA level (or, if their pref_ou is SITKA ... which would be
odd)
2) Only display links when searching at a location deeper than a Federation
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.
==========
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
More information about the Open-ils-dev
mailing list