No subject

simplify a unique set of daily tasks, that is, the receiving of journal =
issues. This process can *trigger* cataloging and copy related events, but =
it does not *control* them. When an issue is received, the holdings record =
ideally gets updated, and circulation/copy information may or may not be =
created depending on need. At that point serials module involvement =
effectively *ends*. Any copies created are now managed as a copy, and the =
MFHD record can be further edited by the cataloger. Changes to the MFHD =
are not reflected in the serials interface, as the serials information is =
now transactional history, not live data. Similarly, changes to any =
created copies do not get reflected in the serials interface; they are now =
simply item assets like anything else.

Pros: simpler integration of current holdings information, easier =
separation of responsibilities, more likely to support unusual situations =
by allowing for 'manual' changes to the holding records and items, =
libraries can start manually and seamlessly add automation later, =
development can happen incrementally
Cons: serial issue 'lifetime' not tracked comprehensively, partial =
automation mixed with manual changes will not be 100% coherent


Progressive:
A progressive approach says that serial issues should be tracked end-to-end=
 (from prediction, to live item, to possible discard) in one interface. =
Holdings are computed based on current database entries only, directly =
reflecting the state of the system (manual editing of 85x/86x MFHD pairs =
will no longer be permitted). Physical issues rather than workflow events =
are treated as primary, and are dealt with at a 1-to-1 level.

Pros: data is kept consistent (events, items, and holdings information are =
directly linked), management practices will be more predictable across =
different institutions
Cons: Limited ability to work around system limitations (and therefore a =
greater need for comprehensive development), migration of current holdings =
data will be somewhat more intensive, limited options for piecemeal =
implementation, possible alienation of MFHD adherents


Recent serials development has been primarily conservative, but that seems =
likely to change very soon. We are not making these decisions lightly, as =
we will certainly take some short-term losses. What we hope for will be =
long-term gain, as it will be simpler to add flexibility to a base of =
consistency rather than the other way around. Whether we can ever add =
enough flexibility to our rigid base to make a truly comprehensive system =
is the unknown risk we will be taking.

Please let us know if you have any perspective to add. Are visible, =
editable MFHD records truly necessary, or should holding statements =
directly reflect the underlying data? Should serial assets be directly or =
loosely tied to the serial management data? Are there any major considerati=
ons we are simply missing entirely?

Thank you for any input you might provide,
Dan (on behalf of the serials developers)