On May 28, 2008, at 13:45, "Mike Rylander" <[EMAIL PROTECTED]> wrote:
On Wed, May 28, 2008 at 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.
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
[EMAIL PROTECTED]
