[OPEN-ILS-GENERAL] Feature Request: Roaming Items, Automatic Item Location Changing

[Mike Rylander]

On Wed, May 28, 2008 at 12:14 PM, Josh Stompro <stomproj at larl.org> wrote:
> This is a feature that my library system is tied to so it would need to be
> in place for us to consider migrating.  We have found the feature to be very
> useful to our system, with very few problems.  I apologize if this has
> already been discussed.  I searched the mailing lists and documentation wiki
> for anything similar to this and didn't see anything.

We've thought about it, but there's nothing written down today.
You've got my design juices flowing, though, and I have some ideas
I'll throw out there for others to comment on.

First, we have some underlying infrastructure now to support transit
persistence.  There's a persistant_transfer field on
action.copy_transit (yeah, it's misspelled...) which is meant to be
used (in the future) for processes like what you describe.  The idea
would be to set this flag on the transit if any base-line static rules
about "floating" the item in question suggest that it is allowed and
desirable.

We need a way of marking an item as floating, and to what set of
branches it should float.  The first thing that comes to my mind is to
do this a the copy_location level -- this is what, in the end, is
usually what librarians think of as a "collection code."  So, we add a
float_to field to asset.copy_location and to asset.copy.  In this
field we record one of three things:

 * the highest org unit in the org tree to which covers the locations
that the items can float
 * the (negated) id of the org_lasso[1] group that the item can float
within (setting the value to x * -1 flags this as a lasso ID instead
of an org unit ID)
 * null -- it doesn't float

So, at transit initiation, we check the destination against the copy's
(and copy location's, as a fall-back) float_to and see if the
destination is covered.  If so, we set the persistant_transfer flag.
When the item shows up at the destination we do any optional
title-level checks to see if the item should stay here (is it a
duplicate? not enough local holds? etc) and if not, ignore the
persistant_transfer flag.  If it /should/ stay, then we change the
circ_lib on the copy to be the transfer destination, making it stick
at the destination location.  We can find the original circ_lib for
these items by looking at the copy_location owner, and pull them back
by unsetting the float_to field on the copy_location (and maybe on the
copy) and setting the circ_lib to the copy_location owner.

Thoughts?

--miker

[1] org lassos are a new org_unit grouping contruct available in trunk
which allow searching among arbitrary, librarian assigned groups of
locations -- they represent logical groupings not modeled in the org
hierarchy

>
> Brief Description:
>   This feature allows items to be freely moved between locations and not
> need to be return to a home/owning location after being transfered to
> another location.  When the item is checked in at a new location, the last
> step is to change the item location to the check-in location.  III refers to
> this feature as floating collections.
>
> Benefits:
>  - Automatic item rotation.  A branch's collection is more dynamic because
> of new items coming in based on what customers request.
>  - Less delivery.  Items don't need to make a return trip to a home
> location, so the item isn't sitting in transit and is on the shelf.
>  - Items migrate to where they are wanted, closer to those that might check
> them out.  If one person at a location wanted something, there is a chance
> that there is more interest in that item or type of item at that location.
>
> Target Audience:
>   Library Systems with > 200,000 items and 2 or more branches for items to
> move to.  This would probably be more welcome in systems that have a
> centralized budget and acquisitions department since it would be affecting
> local branch collections.  Branches that do their own collection development
> would probably not like their carefully selected collection getting messed
> up, although they might like it for certain subsets of the collection.
>
>
> Use Case:
>
> Patron 1 with a home library of Branch A requests an item from Branch B.
>  The item gets sent from Branch B to Branch A.  On check-in at Branch A, the
> location of the item is changed to Branch A.  When Patron 1 is done with the
> item, it is placed on the shelf in Branch A, not sent back to Branch B.
>  Basically the items sticks to where it was placed last.
>
> Configuration:
>   These configuration items should be considered to make the system
> flexible.
>
>  - Which items can roam based on item type/material type/stat category/etc.
>  - Shelving location translation, when an item changes location it will
> probably need to go to a particular shelving location, which might need a
> translation table between locations.
>  - Which org tree objects will participate with other org tree objects.
>  Which branches will participate with other branches.  Which systems will
> participate with other systems.
>  - One way roaming, where an item can roam from branch A to branch B, but
> not the other way around.  Might be useful for a technical services location
> that routes items around.
>  - Two way roaming, where branch A and branch B can share back and forth.
>  - Store the original home location
>
> Other Considerations:
>   Material balancing/distribution.  There might be situations where 2+
> copies roam into a location.  If it is a large branch then maybe no one
> would care.  If it a small branch then they might only want one copy on
> their shelves.  It would be nice if the system could deal with multiple
> copies by looking at several factors like outstanding holds, collection
> size, configuration options, etc.
> Psuedologic
> On check in
>   If item location != checkin location then Roam Check
>      If Item not allowed to roam to location
>         Return Do_Not_Roam
>      If isset avoid duplicates and duplicate exists
>         If outstanding holds at this branch < 2
>            Return Do_Not_Roam && set in transit to home location || choose
> new location
>         else
>            Return Roam because there are multiple holds
>     Return Roam
>
> At what part of the check in process the roam process would take place needs
> to be discussed also.  It should probably be in the Transit decision
> section.  Or should it happen before the system looks for a hold to target,
> so that it can target a local hold and not need to spend any more time in
> transit.
>
> Thank you for considering this request.
> Josh Stompro
>
> --
> Lake Agassiz Regional Library - Moorhead MN larl.org
> Josh Stompro               | Office 218.233.3757 EXT-139
> LARL Network Administrator | Cell 218.790.2110
>
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com