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

[Garcia, Elizabeth]

Josh, 

We have a non-PINES library system in Georgia that wants "roaming
collections" in place before they make a formal move to become a member of
PINES. 

Elizabeth McKinney de Garcia
PINES Program Director
Georgia Public Library Service
A Unit of the University System of Georgia
1800 Century Place, Suite 150
Atlanta GA 30345
404.235.7141
egarcia at georgialibraries.org
http://www.georgialibraries.org/


On 5/28/08 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.
> 
> 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