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 [EMAIL PROTECTED] http://www.georgialibraries.org/ On 5/28/08 12:14 PM, "Josh Stompro" <[EMAIL PROTECTED]> 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
