[OPEN-ILS-DEV] URI scoping in Evergreen
Kathy Lussier
klussier at masslnc.org
Thu Jul 17 11:01:36 EDT 2014
Hi Liam,
> 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.
>
It sounds like this would be a nice extension of the recent located URIs
as copy development. In our case, we are most concerned with seeing
those Located URI's when searching at depth 0, but I think the
additional flexibility here would be a good thing.
> 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.
>
+1. If and when our largest consortium starts using the located URIs as
copy feature, I'm sure they will appreciate the ability to control how
many URIs display here.
> 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 agree with Mike that this sounds like a separate enhancement.
I'll leave the ways and means to you, Mike and the other devs, but I
just wanted to send along feedback that this all sounds like a positive
direction. Thanks for tackling it Liam!
Kathy
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier
On 7/16/2014 7:28 PM, Liam Whalen wrote:
>
> On Jul 16, 2014, at 5:42 AM, Mike Rylander <mrylander at gmail.com
> <mailto: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.
>
>>> 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.
>
>> 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 <http://actor.org>_unit_full_path, or actor.org
>> <http://actor.org>_unit_simple_path (which would
>> replace the call to actor.org <http://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?
>
>>
>> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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 <mailto: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
>>>> <mailto: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 <mailto: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 <mailto: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/d5c99852/attachment-0001.htm>
More information about the Open-ils-dev
mailing list