[OPEN-ILS-DEV] Modifications to Circ Matrix Matchpoint checking

[Mike Rylander]

There as been a /lot/ of discussion surrounding this functionality on
IRC over the last week, just to let everyone here know that it's not
being ignored.

More below.

On Tue, Sep 7, 2010 at 4:29 PM, Thomas Berezansky <tsbere at mvlc.org> wrote:
> My previous email included a patch that was, unfortunately, just the tip of
> the iceberg, so to speak. I have since figured out a lot of what needs to be
> done to do this on the backend.
>
> However, in looking at what needs to be done, I came up with several
> questions as to how to handle things.
>
> Currently the circulation flag, duration rule, recurring fine rule, and max
> fine rule are on my list of things to have "fall through".
>
> I am unsure as to whether or not to have the total copy hold ratio or the
> available copy hold ratio values fall through or not. They are not
> "endpoint" data, but at the same time may be considered to be an important
> part of the checks.
>
> In that regard, I see three logical options:
> 1 - Don't have them fall through. If they aren't set on the first matchpoint
> found, they aren't set.
> 2 - Have them fall through until we run out of rules or they are filled,
> like the four values above.
> 3 - Have them fall through, but only until we have filled the other four
> values. Once the other four values are filled we officially stop checking
> them.
>
> I am partial to 1 or 3 in this case.
>

After discussion, option 3 seems sane and has gained general
consensus.  One point I brought up was, how do you tell the system
that you do /not/ want to use an inherited test value and also don't
want to supply a value?  IOW, what if you don't want to test a
copy-hold ratio and yet some broader rule does set a value for one of
these tests?

The answer is that a value of 0 (zero) acts the same as "don't test"
since all possible values will pass.

> The other main issue I am seeing right now is the circ mod test. In
> particular, the current system uses the matchpoint ID for the check. As my
> changes make it so that there is more than one matchpoint ID possibly
> involved there are several options:
>
> 1 - Negate the check when there is more than one matchpoint used in the
> final result
> 2 - Use only the first matchpoint found for the check
> 3 - Have it use all matchpoints that were considered for the check (were
> valid and before we filled in our values)
> 4 - Have it use all matchpoints that contributed to the check (were valid,
> before we filled in our values, AND set at least one value)
>
> I am partial to 3 in this case, as that would allow for creating a
> matchpoint that would be specifically for triggering that limit, without
> changing any of the resulting rules.
>

This question has not been addressed yet.  I think that without
broader input, and in fact outside requests, we need to sit on this
one.  I understand the argument for the flexibility of 3, but these
matchpoints and rulesets can already be very complicated, and the
potential for SAAD is high.  Consider:

 * matchpoint 1 (closest match) supplies all but max fine rule, and
has a circ-mod test for "book" that limits the user to 10 items out
 * matchpoint 2 (fall-through by group) supplies the max fine rule,
and also has a circ-mod test for "book", but sets the limit at 5 items
out

Which do we honor? And, like the question about copy-hold ratios, how
do we say "do NOT test per-circ-mod items out at all"?  There are no
magic values here, and the benefit of flexibility IMO is outweighed by
the complexity of getting it right from a user perspective.

> Any thoughts?
>

All that said, I think this is some awesome work.  Thanks, Thomas!

--miker

> Thomas Berezansky
> Merrimack Valley Library Consortium
>
>
> Quoting Thomas Berezansky <tsbere at mvlc.org>:
>
>> Theory:
>> Make the things returned (circulate, duration_rule,  recurring_fine_rule,
>> max_fine_rule) "fall through" when set to NULL.
>>
>> The attached patch attempts to make this happen on the back end, but
>>  provides no front end interface changes for configuring it.
>>
>> IT HAS NOT BEEN TESTED, mainly because I don't want to screw with our
>>  test system right now when others may be trying to test existing
>>  functionality.
>>
>> It also adds in the ability to pass in one more (optional) boolean
>>  parameter to the function to return the entire list of rules used to
>>  create the final result, intended for "debug/test" front end  functionality
>> to show what rules were considered in the fall-through  checking.
>>
>> Pros:
>>
>> You can override a subset of those fields with a specific rule while
>>  allowing broader rules to fill in the holes.
>> This may result in less duplication of information across rules,  making
>> things easier to maintain.
>> Thus, this may result in less rules in general, and thus less  processing
>> time on sorting them overall.
>>
>> Cons:
>>
>> Manually figuring out the specifics of what will happen will take more
>>  time/effort.
>> Changing a single rule may have a greater unintended effect on other
>> rules.
>> Staff would need training for when to have a rule fall through and  when
>> to set it.
>> More time to return from the DB for any rule that is "falling through"  to
>> broader rules.
>>
>> Examples for the following org tree:
>>
>> CONS
>> -SYSA
>> --LIBC
>> --LIBD
>> -SYSB
>> --LIBE
>> --LIBF
>>
>> Implementing the following "business" rules:
>>
>> At the CONS level:
>> By default, everything circulates, uses DFLT_DUR duration, DFLT_RFINE
>>  recurring fine, and DFLT_MFINE max fine.
>> Circ Modifier "book" uses the duration BOOK_DUR
>> Reference flagged materials don't circulate
>>
>> At the SYSA level there are no special rules.
>>
>> At the SYSB level the max fine should be SYSB_MFINE.
>>
>> At the LIBC level the recurring fine is LIBC_RFINE
>>
>> At the LIBD level circ modifier "book" uses the DFLT_DUR duration  instead
>> of "BOOK_DUR"
>>
>> At the LIBE level reference flagged materials circulate.
>>
>> At the LIBF level there are no special rules.
>>
>> The current method would require the following circ rules to implement
>>  those business rules:
>>
>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>> CONS     NULL     NULL      TRUE  DFLT_DUR      DFLT_RFINE     DFLT_MFINE
>> CONS     NULL     TRUE      FALSE DFLT_DUR      DFLT_RFINE     DFLT_MFINE
>> CONS     book     NULL      TRUE  BOOK_DUR      DFLT_RFINE     DFLT_MFINE
>> CONS     book     TRUE      FALSE BOOK_DUR      DFLT_RFINE     DFLT_MFINE
>> SYSB     NULL     NULL      TRUE  DFLT_DUR      DFLT_RFINE     SYSB_MFINE
>> SYSB     NULL     TRUE      FALSE DFLT_DUR      DFLT_RFINE     SYSB_MFINE
>> SYSB     book     NULL      TRUE  BOOK_DUR      DFLT_RFINE     SYSB_MFINE
>> SYSB     book     TRUE      FALSE BOOK_DUR      DFLT_RFINE     SYSB_MFINE
>> LIBC     NULL     NULL      TRUE  DFLT_DUR      LIBC_RFINE     DFLT_MFINE
>> LIBC     NULL     TRUE      FALSE DFLT_DUR      LIBC_RFINE     DFLT_MFINE
>> LIBC     book     NULL      TRUE  BOOK_DUR      LIBC_RFINE     DFLT_MFINE
>> LIBC     book     TRUE      FALSE BOOK_DUR      LIBC_RFINE     DFLT_MFINE
>> LIBD     book     NULL      TRUE  DFLT_DUR      DFLT_RFINE     DFLT_MFINE
>> LIBD     book     TRUE      FALSE DFLT_DUR      DFLT_RFINE     DFLT_MFINE
>> LIBE     NULL     NULL      TRUE  DFLT_DUR      DFLT_RFINE     SYSB_MFINE
>> LIBE     book     NULL      TRUE  BOOK_DUR      DFLT_RFINE     SYSB_MFINE
>>
>> 16 circ rules total.
>>
>> The new method would require the following circ rules to implement  those
>> business rules:
>>
>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>> CONS     NULL     NULL      TRUE  DFLT_DUR      DFLT_RFINE     DFLT_MFINE
>> CONS     book     NULL      NULL  BOOK_DUR      NULL           NULL
>> CONS     NULL     TRUE      FALSE NULL          NULL           NULL
>> SYSB     NULL     NULL      NULL  NULL          NULL           SYSB_MFINE
>> LIBC     NULL     NULL      NULL  NULL          LIBC_RFINE     NULL
>> LIBD     book     NULL      NULL  DFLT_DUR      NULL           NULL
>> LIBE     NULL     TRUE      TRUE  NULL          NULL           NULL
>>
>> 7 circ rules total.
>>
>> Starting with the above, lets assume that SYSA wants to change their
>>  recurring fine to SYSA_RFINE.
>> LIBC's recurring fine is to be unchanged.
>>
>> The current method requires the following changes:
>>
>> ADD the following entries:
>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>> SYSA     NULL     NULL      TRUE  DFLT_DUR      SYSA_RFINE     DFLT_MFINE
>> SYSA     NULL     TRUE      FALSE DFLT_DUR      SYSA_RFINE     DFLT_MFINE
>> SYSA     book     NULL      TRUE  BOOK_DUR      SYSA_RFINE     DFLT_MFINE
>> SYSA     book     TRUE      FALSE BOOK_DUR      SYSA_RFINE     DFLT_MFINE
>>
>> UPDATE the LIBD entries:
>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>> LIBD     book     NULL      TRUE  DFLT_DUR      SYSA_RFINE     DFLT_MFINE
>> LIBD     book     TRUE      FALSE DFLT_DUR      SYSA_RFINE     DFLT_MFINE
>>
>> 4 rules added, 2 changed, total is now 20 rules.
>>
>> The new method would require the following changes:
>>
>> ADD the following entry:
>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>> SYSA     NULL     NULL      NULL  NULL          SYSA_RFINE     NULL
>>
>> 1 rule added, 0 changed, total is now 8 rules.
>>
>> Thomas Berezansky
>> Merrimack Valley Library Consortium
>>
>
>
>



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