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

[Mike Rylander]

On Thu, May 29, 2008 at 9:49 PM, Paul Waak <ptwaak at gmail.com> wrote:
>
> 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

Well, this is a first draft, so expect it to be refined more. :)

(Josh has already started that ... Josh, I'm thinking about your later
response more now, and I'll respond as soon as I can.)

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

The schema relevant to org_lassos currently looks like this:

CREATE TABLE actor.org_lasso (
    id      SERIAL  PRIMARY KEY,
    name    TEXT    UNIQUE
);

CREATE TABLE actor.org_lasso_map (
    id          SERIAL  PRIMARY KEY,
    lasso       INT     NOT NULL REFERENCES actor.org_lasso (id) ON
DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
    org_unit    INT     NOT NULL REFERENCES actor.org_unit (id) ON
DELETE CASCADE DEFERRABLE INITIALLY DEFERRED
);
CREATE UNIQUE INDEX ou_lasso_lasso_ou_idx ON actor.org_lasso_map
(lasso, org_unit);

That schema will be fleshed out over time to include ownership
information and usage metadata.

Both the org_unit and org_lasso objects have a numeric id field which
is constrained to positive numbers.  Since those two object types
represent mutually exclusive ways of grouping libraries
(organizational units) together -- strict hierarchy of parent-child
relationships on the org unit vs arbitrary grouping by lasso -- we use
the negated value of the lasso id to signal that the group in question
is, in fact, a lasso instead of an org unit (which would have its
natural, positive value).

Because an org unit by itself can be treated as a grouping mechanism
for all of its descendants (and the lassos have (for the purpose here)
grouping as their main property), we can simplify the code by having a
single function return the list of inferred locations that interprets
the value based on its sign.

So, to answer your original question (I'm long-winded even in
email...), when we need a defined group of locations we pass around is
the id field from either the actor.org_unit or actor.org_lasso.
(Also, just to complicate things a bit, org units also have an
associated tree depth, and you can use that to ask for an ancestor of
the context org unit (at the requested depth) and its children instead
of the specific context org unit you have in hand.  That's how we do
ranged searches in the OPAC, where you can focus on a branch but
search the entire system -- Branch context org with System depth.  Org
lassos do not have such a hierarchy, so no depth there.)

Does that answer your questions?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com