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

Josh Stompro stomproj at larl.org
Wed May 28 12:14:36 EDT 2008


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

-- 
Lake Agassiz Regional Library - Moorhead MN larl.org
Josh Stompro               | Office 218.233.3757 EXT-139
LARL Network Administrator | Cell 218.790.2110	



More information about the Open-ils-general mailing list