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
