[OPEN-ILS-GENERAL] Recalls and Reserves and Patrons, oh my!

[David J. Fiander]

On 29-Mar-07, at 04:39 , Jason Etheridge wrote:

>
> 1) Recalls.  Basically, you can have someone like a Professor borrow
> an item indefinitely, until someone else wants the item, at which
> point the Professor gets notified and is supposed to return the item.
> This is probably do-able under the hood now, though there isn't
> interface support for it currently.  We basically create a hold type
> of Recall and let it trigger such actions as emailing the current
> borrower, and maybe resetting the due date for the existing
> circulation.

At MPOW, we don't have 'holds.'  If somebody has a book checked out,  
and I want it, all I can do is recall it.  If there are multiple  
people that recall it, then we end up with a hold queue, and  
everybody in the queue gets a shortened borrowing period.  In an  
academic setting, that's fine: an item with three outstanding holds  
is deemed to be "heavy use" and automatically placed on 2hr reserve.

>
> 2) Reserves.  Basically, materials are set aside (by say, a Professor)
> to be used by a specific group of people (maybe everyone taking a
> particular course or class).  One way this could be done today is by
> creating a shelving/copy location of Reserves (maybe one for each
> course) for a library and giving it default properties of Non
> Circulating and Non Holdable for items in that location.  Then it
> would be a matter of putting patrons/students into certain permission
> or profile groups for those courses making use of reserves, and having
> the circ rules make exceptions when it encounters those.  For example,
> a shelving location of Reserves - Math 101 is non circulating to
> students by default, but if a student is a member of the Math 101
> Reserve group, then the circ rules will allow them to circulate an
> item from that location.  What we're missing today is an easy GUI for
> such group and circ rule manipulation.

We don't restrict reserves to a select few, but our system does have  
a "reserves component", so that we can associated materials with a  
course name and an instructor.  Our system handles the non-holdable  
part of the equation by not allowing holds to be place on any item  
that has a "special" borrowing period.  That sort of 'non-holdable'  
handling would also be useful for public libraries that have a "best  
sellers" collection, that circulates with a shorter borrowing period  
and can't be held (say they have a bunch of Harry Potter than circ  
normally and can be held, and one copy per branch that can be  
borrowed for a week, and can't be renewed or held, so people that are  
browsing the library have a chance to get it).

>
> 3) External patron file/data.  This came up in a talk recently;
> basically some libraries would like to
> feed/create/update/synchronize/etc. the ILS patron records with
> information from a central/external patron database (from say, the
> Registrar's office), and maybe go in the other direction as well (the
> school's account for a student could get flagged if the student has
> unresolved issues at a library).  This is doable, and was basically
> done in PINES with the migration of Patron data from the old system to
> Evergreen.  In general, given any consistently formatted (and keyed or
> indexed) data, we can map that data into Evergreen.

There are two parts to this.  First, at MPOW, we get a data file from  
the registrar's office with patron info that includes patron type,  
address, email, and we load it into the ILS, translating university  
user types into their equivalent library patron types.  The nice  
thing about this is that we don't care about maintaining addresses  
for most of our users (alumni we have to track ourselves, for example).

Secondly, for primary patron types (ie, folks that the registrar  
tells us about), the ILS calls out to the central LDAP server to  
authenticate usenames and passwords to access the library account.   
While I definitely like the fact that Evergreen lets users create  
their own usernames, I think that that's more useful for a public  
library than for a large academic institution that already has a  
'single-id' sort of environment based on the central computing account.

- David

-- 
David J. Fiander
Digital Services Librarian