[OPEN-ILS-DEV] URI scoping in Evergreen
Hardy, Elaine
ehardy at georgialibraries.org
Thu Jul 17 09:17:34 EDT 2014
OK. See the concept now.
I am concerned with the size of the brief record in the result set
particularly with the length of this particular public note. A large result
set could become unwieldy, requiring the user to scroll through a lot of
pages. Would the number of links displayed on the list be configurable?
Elaine
J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax
ehardy at georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines
-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org
[mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Liam
Whalen
Sent: Wednesday, July 16, 2014 7:50 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] URI scoping in Evergreen
> On Jul 16, 2014, at 10:02 AM, "Hardy, Elaine"
> <ehardy at georgialibraries.org> wrote:
>
> If I understand correctly, you want a user to be able, from the
> result list and the OPAC view, to see a list of the libraries in the
> |9 on the
> 856 along with the link to the e-resource where they would normally
> see a list of barcoded items with their call numbers, etc.?
>
This is not what I was suggesting, but we are considering putting the |9
value in the notes part of 856 |y.
> How would a record where the 856 does not have a |9 so that it Is
> available to the entire consortium? For example, we added all free
> online versions of The king in yellow to PINES so that all PINES
> library users had access in searches scoped to their library
> (http://gapines.org/eg/opac/results?query=king+in+yellow&qtype=title&f
> i%3A item_type=&locg=66). The 856 for one record (second one in the
> linked
> search) is:
>
> 856 40 ‡uhttp://www.gutenberg.org/etext/8492 ‡yClick here for Project
> Gutenberg full text.
>
> We also have a number of US govdocs with either |9PINES or no |9.
>
Currently we are only concerned with located URIs (which are those 856
values with |9). Our use case for 856 without |9 is to display them
whenever the record would normally be displayed,
> I do think it is a great idea; but, like Mike would like more information.
> For me, I want to understand and visualize the end user results in the
> OPAC view.
>
You can see this in action now on our dev1 server here:
http://www.dev1.catalogue.libraries.coop/eg/opac/results?query=107405744&qtype=keyword&fi%3Asearch_format=&locg=1101
Note, in this case these changes have all been made at the TPAC level, which
is completely different from the way Mike is proposing to do things, which
is the correct way of handling the situation because it will reduce data
transferred across the wire and separate logic from display.
Liam
> Elaine
>
> J. Elaine Hardy
> PINES & Collaborative Projects Manager Georgia Public Library Service
> 1800 Century Place, Ste 150
> Atlanta, Ga. 30345-4304
>
> 404.235-7128
> 404.235-7201, fax
> ehardy at georgialibraries.org
> www.georgialibraries.org
> www.georgialibraries.org/pines
>
> -----Original Message-----
> From: open-ils-dev-bounces at list.georgialibraries.org
> [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of
> Liam Whalen
> Sent: Tuesday, July 15, 2014 6:17 PM
> To: Evergreen Development Discussion List
> Subject: Re: [OPEN-ILS-DEV] URI scoping in Evergreen
>
>
>> 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.
>
>
>> * 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.
>
>> * 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.
>
>> * 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.
>
>> * 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?
>
> 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.
>
> 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.
>
> In all other cases, if the URI would not be displayed for the search
> or pref OU, then the record should not be displayed.
>
> 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.
>
>>
>> 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.
>
>> 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
>
More information about the Open-ils-dev
mailing list