[OPEN-ILS-DEV] SRU stuff, 2.1+

[Dan Scott]

On Thu, Mar 03, 2011 at 12:01:10PM -0500, Mike Rylander wrote:
> Dan Scott (very) recently made a great improvement to our
> SRU-to-search code by converting the hard-coded index definition map
> to use the actual configuration data available in 2.0+.  First,
> thanks, Dan, for taking it the last mile!

Well, the first kilometre of the last mile, maybe.
 
> On that front, there's some more we can do.  Dan and I have discussed
> in IRC a couple of these things, particularly relaxing the alias
> inclusion and adding in some static filters and modifiers as index
> axes.  Here's a list of those static filters which we have:

<snip> 

> Not all of these need to be (or, necessarily should be) supported
> directly by the explain doc, but some should.  My rough guess would
> be:   available, ascending, descending, sort, format, before, after,
> statuses, locations, site, depth, lasso, offset, limit,
> preferred_language, preferred_language_weight and
> preferred_language_multiplier.

Done and done. We also have a working SRU explain document for the
authority SRU interface now (whee!). And for good measure I backported
the fixes to 2.0 (minus the authority stuff, naturally).

Next step in 2.1/trunk is to add a description column to the
config.metabib_search_alias table so that we can draw the descriptions
of each index from the table, rather than keeping them in sync in the
Perl module manually. Some people may want to have a hint of what
"se" means :) In IRC you had mentioned a few other tables that should
get this treatment too, I believe?
 
> Now, why haven't I mentioned things like the valid values for sort
> axis, or things like audience() and item_form() filters? Because they
> are now covered by the SVF topic branch's configuration, and can be
> pulled in in the same way that search classes, fields and aliases are
> (though we're only using aliases today, which for SRU seems correct to
> me).  So this can be considered a sly way of opening the "Mike wants
> to merge in SVF now" discussion.
> 
> Thoughts or comments on either the hard-coded filters stuff or SVF merge?

Although I welcome the improvements to fine-grained searching that
things like audience and item form bring, in practice we've found the
quality of our MARC records to often lead searchers to dead ends when
they've tried using the advanced options in these areas in the past.
Part of that is out and out QA problems in the record, and part of it is
confusing library terminology (when they limit to "Format = Electronic
resources" they're thinking e-journals and e-books, and they're getting
CD-ROMs) -and as far as I know, there currently is no good way to give
them a search that does what they're asking for.

You mentioned that providing a search scope for asset.uri resources
would be possible via SVF, so that definitely has my interest as it
seems to be a great way to provide a good solution to this problem :)