[OPEN-ILS-DEV] URI scoping in Evergreen
Mike Rylander
mrylander at gmail.com
Thu Jul 17 07:49:59 EDT 2014
Lots inline...
On Wed, Jul 16, 2014 at 7:28 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:
>
> ...
>
> * 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.)
>
>
> I had a meeting with support today. I will reexplain our use cases at the
> end of this email.
>
> * 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"
>
>
> Our requirement is more than ignoring the SITKA-owned LURIs. It also
> silos off each 2nd level OU from the other.
>
>
Well, right. What I mean by "ignore SITKA-owned LURIs" is that when the
search context OU is anything other than the top of the org tree -- that
is, has an OU Type with a Depth greater than 0 and in the hypothetical
configuration you'd set up under my proposal would have a direct or
inherited "opac.luri_ancestor_visibility_depth" value of 1 (Federation type
depth) -- then only LURIs from the Federation (and all descendants) of the
search context* OU would contribute to visibility. I'm sorry, I took it as
granted that we were on the same page there. To restate another way, for
your use (and if configured as I described before) only those LURIs owned
by an OU within the subtree of the hierarchy that is parented at depth 1 by
the context* OU's Federation would matter to the search, for both
visibility of the record and for display in whatever form is available.
(* And pref_ou, but those will be intra-Federation peers in all reasonable
cases for SITKA patrons, and explainable (well-defined) when not.)
> 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.
>
>
> Here is what I was trying to communicate. Aside from cases where we
> explicitly do not want URIs being displayed, the records should be scoped
> according to the fenced of area of the URI. So, if the Search OU or Pref OU
> falls within the fencing, then the record should be returned in the search
> results. However, copies still need to be considered because a record
> might have a copy owned by one library which does not have a 856 $9, and it
> might also have a library with an 856$9. In that case, the record needs to
> be displayed in the search results for the first library in the manner that
> copy visibility currently works. In the second case the record needs to be
> displayed in the manner we are currently discussing. I believe the
> luri_act_as_copy flag currently removes records with copies but not 856 $9
> from the results when there are non-relevant (to the search or pref OU) 856
> $9 values within the record.
>
>
luri_act_as_copy absolutely should /not/ be removing records with visible
copies but no visible 856$9. If that is happening, it is a bug and I would
be very interested in seeing an example so I can squash it.
For non-deleted records, visibility testing is designed to be inclusive,
not exclusive, so if anything causes a record to be included in the result
set (visible copy, visible LURI, transcendent, completely empty (for
staff)) then it is included -- period.
> 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.
>
>
> If LURIs as copies is not enabled when these values are passed in, then
> would we lose our descendant scoping?
>
>
"LURIs as copies" changes the descendant side of the effective range of the
LURI, while the proposed opac.luri_ancestor_visibility_depth YAOUS would
change the ancestor side of that range. They're conceptually orthogonal.
I was just pointing out that, while conceptually distinct, we can optimize
the implementation of adding opac.luri_ancestor_visibility_depth by simply
changing the way we build the LURI range array. Sorry if this led to any
confusion.
But, to answer your question, yes, if you turn off the "LURIs as copies"
flag, you lose the "include descendant-owned LURIs" behavior. I'm not
suggesting that SITKA do that, or that you would need to do that in order
to use the hypothetical new opac.luri_ancestor_visibility_depth YAOUS.
>
> 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.
>
>
> That is good to know.
>
>
> The uses we need these changes for are as follows.
>
>
> To begin I will define our OU depths. 0 is Sitka, 1 is a Federation. Our
> Federations are distinct and do not share URIs between them. 2 and below
> are either systems, subsystems, or branches. At 2 and below, URIs can be
> located to a system. In this case, branches and subsystems need to see
> records and URIs. URIs can be owned by a subsystems. In this case,
> branches and systems need to see records and URIs. Finally, URIs can be
> owned by branches. In this case, URIs need to be seen by subsystems and
> systems.
>
>
> In the end, this boils down to three requirements. All children of the
> search OU need to be checked for located URIs. And all Parent OUs below
> depth 1 need to be checked for located URIs. Also, if an URI is owned by
> the Pref OU, it should be displayed as well.
>
>
>
This (and in specific, "all Parent OUs below depth 1") is exactly what the
new opac.luri_ancestor_visibility_depth YAOUS would cover.
> We had a discussion about removing the Pref OU from the search results
> when it is not within the Org Tree of the search OU, and we decided that we
> are better off not doing that. So, that part of my original email can be
> ignored.
>
>
> There is a new requirement. One of our Federations allows patron
> searching at the Federation level. In cases like this, we would like these
> Federations to display URIs in search results and records. This should be
> covered by your opac.luri_results_display.context, but we would also need
> it to apply to the record view as well.
>
>
>
This is, indeed, covered already. Let me step back for a moment to define
some terms, as there are several similar ones in use in this area:
* Result Record -- a record that is visible to the user, for the search,
because of copies, LURIs, transendency, etc
* Result Set -- those records found by a search
* Result List -- the display of the list of records in the Result Set
* Record Detail -- the display of just one record, in full detail, from a
Result Set
Only visible (in range) LURIs are included in the Result Set -- "foreign"
LURIs are not even attached to the holdings section of the XML for the
Result Records. The Record Detail page currently acts exactly this way,
because it uses the holdings XML to render the list of LURIs.
So, the two YAOUS' I propose above that modify display are only intended to
help the TPAC know when to show LURIs on the Result List. All visible (in
range) LURIs would be displayed on the Record Detail page, in all cases.
In the SITKA configuration, this would include SITKA-owned and "foreign"
Federation LURIs in exactly two cases: when the user searched all of SITKA,
or the user's pref_ou was SITKA. Does that help clarify?
Now, if you want to conditionally change when the list of visible LURIs is
rendered on the Record Detail page, that would be best covered by one or
more separate YAOUS' ... but I don't think that's the case. IIUC, all
in-range LURIs should always be displayed on the Record Detail page. And
remember that "in range" would now be modified
by opac.luri_ancestor_visibility_depth, so for your case SITKA and
"foreign" Federation (and descendants) LURIs would not be in range, and
therefore not included in the holds XML, so they'd never be considered for
display at the TPAC level.
Next, in cases when a record has more than n URIs and they are returned in
> the search results and those URIs will be displayed, then we would like the
> search results to display only n URIs and to display a 'More...' link after
> them taking the user to the record. In our case n = 5.
>
>
>
This, much like callnumber display on the result list (when in "show more
info" mode), seems like a job for the TPAC code. We're already sorting the
LURIs using the same ranking we do for call numbers, so that should "just
work" if implemented the same basic way.
> Finally, to perhaps complicate the issue, LP1297838 is requesting the
> ability to display 5xx based on $5. We might want to consider combining
> the URI $9 solution with LP1297838, since they both could deal with
> modifying the XML returned to the TPAC.
>
>
>
I think that bug needs to stand on its own for now. It can certainly be
worked on in parallel, and draw inspiration from whatever we end up doing
here, but it will also require additions to indexing and search changes no
matter which of the proposed directions is taken (I prefer the external
note direction, personally, for the overlay reason that Galen mentions) and
is not really about to record visibility, per se, though it does bear on
that.
Overall, I am confident that there are about 10 lines of code to change in
two stored procedures, and some relatively uncomplicated work to be done in
the TPAC to check LURI owner settings and render them (or not) on the
result list. In the end, this looks like a pretty small development by
lines of code, with a pretty big bang-to-buck ratio.
Thanks for continuing to work through this on-list, Liam. I think this
will be a very nice enhancement.
--Mike
Liam
>
>
>
> --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/20140717/7ba6bcf0/attachment-0001.htm>
More information about the Open-ils-dev
mailing list