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

[Paul Waak]

On May 28, 2008, at 13:45, "Mike Rylander" <mrylander at gmail.com> wrote:
> On Wed, May 28, 2008 at 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.
>
> 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.
>
> 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 a 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:
>
>  * 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, 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.
>
> 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

Wow!  I'm glad you've put this much thought into it.  In discussions  
about the Texas SILS project, I have encountered two related  
situations.  Both situations are non-essential but would be  
considered significant features.

In one circumstance, the owning library will only make its collection  
available to consortium members that meet additional criteria.   
Specifically, this is a regional foundation that is willing to make  
material available to consortium members that have Friends of the  
Library groups that are active in the foundation (I hope that made  
sense).  This sounds like a good place for an org_lasso.

The other situation involves interest groups that would like to  
develop special libraries but lack either the storage facility or a  
reliably available staff to operate it or both.  The consortium  
libraries in an interest group's region would provide the storage and  
operation while the IG provides, and owns, the floating collection.

If I understand you correctly, what you describe will handle both  
situations.

My main question is about the org_lasso.  You describe it as an XOR  
value.  Does this mean you routinely pass around the entire list of  
locations as (a pointer to) an ordered bit field?  Or is this a list  
of location tokens with a '-' prefixed?  Your description leaves me a  
bit surprised.

Paul Waak
pwaak at yahoo.com