[OPEN-ILS-DEV] URI scoping in Evergreen
liam.whalen at bc.libraries.coop
liam.whalen at bc.libraries.coop
Thu Jul 17 11:57:15 EDT 2014
Quoting "Hardy, Elaine" <ehardy at georgialibraries.org>:
> 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?
>
Sitka would like the number to be configurable with YAOUS.
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: 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