No subject

at a bib, and if you have an MFHD in hand you have the option of
adding it -- or not, and just add a subscription and the prediction
data(*).  Then for the first case (adding MFHD you have in hand), as
needs dictate, you add the subscription+prediction information,
receive items, and cause "controlled" holdings statements to be
generated -- a linear, additive workflow instead of two separate
processes.

Does restating it like that help explain what I'm imagining?


(*) Side note: because we'll be writing the code to perform the
"one-time migration from MFHD to "controlled" data" anyway, there's no
reason you couldn't add the MFHD and then instruct the system to
extract, for that one record, the prediction data for a new
subscription.  This would make the MFHD "authoritative" only for the
purpose of the initial prediction info extraction, and nothing else
after that -- it would then immediately become "legacy" data.  This,
of course, can come later from a UI perspective, but IMO can be done
clearly, cleanly and with a good performance profile as a stored
procedure in the db.

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