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

[Josh Stompro]

I'm moving this over to Dev, which seems more suited for this 
discussion.  I posted to general in the first place because that is what 
the feature request document specifies. 

Mike Rylander wrote:
> 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.
>
>   
Would this also allow for a feature that many of our staff remember from 
the good ol' DRA days, the "agency request".  The way I remember that 
feature was that it allowed one branch to request items at an 
organizational level, and have them available for checkout for a certain 
period of time, like 3 months.  I believe it was used for things like 
programs, where many items in a related subject area were requested to 
give attendees a wide range of materials to select from.  When the time 
period was over the items would get pulled and sent back to their home 
branch.

How would this handle situations where and item isn't set in transit in 
the first place, like if a customer returned an item at a different 
branch than where they checked it out?  I don't understand the schema 
very well so some of my questions might be obvious. 
> 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 at 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:
>
>   
How would this handle one way floating relationships.  Where an item can 
float from A->B, but not from B->A.    Also, adding a flag to asset.copy 
would mean that a change in what is floated means having to update every 
single record that is affected. (I now see that copy location is looked 
at after copy, so changes could be made on just the copy_location level 
without needing to touch individual records.)  Also, the table would be 
expanded by one more field, which may only get used in a small number of 
copies.  Maybe a rules based approach might be better, but I guess it 
depends on how specific someone might want the floating to be.  If a 
library only wants 10 specific dvd's to float then a per copy approach 
might be best.

What about using the copy stat cats, or would that be an abuse of that 
feature?
>  * 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 if a library system wanted to allow floating to all of it's branches 
and one specific reciprocal branch in another system they would have to 
create a lasso group that contains all of their branches + the one 
location that is strange.  It seems like this would cover most 
situations, except I still don't see how this would represent a one way 
relationship where items can float in, but not out or the other way 
around, but I am basing my thoughts on how our current system works 
without fully understanding how the EG system would work. 
> 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.
>
>   
I'm not sure I understand the benefit of making the floating decision at 
transit initiation, maybe you could pull together a powerpoint, some 
flowcharts, that sort of thing :) hehe. 

What happens when an item floats from location A -> B, then is requested 
by a customer at location C, transits to C....   Even though the item is 
at B, its copy_location is associated with A.  Does this cause problems 
with requesting, paging/pull lists, opac display, etc.  Is a item that 
is floated to another location going to show up as In transit in the 
opac?  This seems more like yo-yo collections rather than floating, the 
item isn't truly part of the new libraries collection, if i understand 
things correctly. 

What if the owning lib connection was completely broken, and if an item 
wasn't wanted at a branch the system would make a decision on where to 
send the item based on some sort of rules.  Would there be any way to 
accommodate that way of think, as well as keeping items somewhat tethered.
Thanks
Josh

> 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
>>
>>
>>     
>
>
>
>   

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