[OPEN-ILS-GENERAL] Reintroducing search range-like features in TPAC

[Bill Erickson]

On Mon, Dec 12, 2011 at 10:24:37AM -0500, Dan Scott wrote:
> On Mon, Dec 12, 2011 at 10:14:24AM -0500, Kathy Lussier wrote:
> > Thanks for taking a look at this Dan!
> > 
> > >>As for one of the elements of MassLNC's document, requesting that
> > >>copies
> > >>be sorted first by library name and then by call number, I've taken a
> > >>stab in that direction by making a branch such that volumes within the
> > >>unapi.holdings_xml database function sort by library name and then call
> > >>number label. There is still a loophole: copies that are circulating at
> > >>a library that is not the volume owner will still appear out of order,
> > >>but at least this moves us closer to the goal.
> > 
> > I just need a bit of clarification here. When you say "copies that are
> > circulating at a library that is not the volume owner" are your referring to
> > the circulation library (as entered in the copy editor) or are you referring
> > to copies that just happen to be circulating at another library after
> > filling a hold? I suspect the former, but, since I initially read it as the
> > latter, I want to make sure I'm understanding this correctly.
> 
> Right, the former (circulation library as entered in the copy editor).
> To jump down to the database level, the remaining problem lies with
> copies where asset.copy.circ_lib is not equal
> asset.call_number.owning_lib - nothing that an extra dose of SQL can't,
> in theory, deal with.
>  
> > >>As for implementing the "show copies that are held by the preferred
> > >>location first" logic, a simplistic approach would be to have the
> > >>Template Toolkit layer check for available copies in the holdings_xml
> > >>via a specific XPath request and then bubble those to the top - but
> > >>that
> > >>won't work for sites with lots of copies and a wide search range,
> > >>because we'll hit problems with paging. So a better route might me to
> > >>use a windowing function in unapi.holdings_xml to rank the results
> > >>based
> > >>on whether the owning library matches the preferred location, and then
> > >>order by rank, library name, and call number label.
> > 
> > If I'm understanding this correctly, then, if my preferred location owns 15
> > copies of a title, the latter method will allow paging after the first 10
> > copies while the more simplistic approach may not be able to handle that as
> > well? Is that correct?
> 
> Not quite. 
> 
> In a working scenario for the simplistic solution, let's say there are 5
> copies total for a given record in the current search scope. If you're
> showing 5 copies per page of results, ordered strictly by library name
> on the database side, then the Template Toolkit layer could iterate
> through those copies to find any that match the preferred library and
> push those copies to the front of the display list. There's no risk that
> any of the matching copies would be in the second or subsequent pages of
> results because there is only one page of results.
> 
> But for a simple non-working example, let's say there are 10 copies
> total for a given record in the current search scope: 5 copies are at
> library "AAAA" and the other 5 are at library "ZZZZ". If you're showing
> 5 copies per page of results, ordered strictly by library name on the
> database side, then all 5 copies on the first page of results are going
> to be from library "AAAA".  There's nothing that the Template Toolkit
> layer of code can do if the user's preferred library is "ZZZZ"; the
> first page of results will be all "AAAA" because that's all that is
> available to Template Toolkit. So the right solution seems to be to
> implement a windowing function that can rank by preferred library (if
> passed in).
> 
> (/me realizes in passing that the CGI param "loc" suggests "location",
> which could be conflated with "copy location" - maybe "lib" would be a
> better choice...) 

Some additional info...

TPac supports a param now called "physical_loc".  It's not exactly the
same as a "prefered library", because it's not meant to be changed by
the user, but it could be used as the default value for prefered 
library (among other default org units) for OPACs within the branch
(i.e. they have a known physical location).  This is the same value set 
by the IP address redirector module.

Its primary purpose thus far has been to affect copy sorting on the
detail page.  If physical_loc is set, any copies whose circ lib matches
will be sorted to the top in the detail page.  json_query handles the
sorting/paging like a champ.  Unapi will certainly need some new nobs 
to do the same thing.

-b

-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com 
| Equinox Software, Inc. / Your Library's Guide to Open Source