[OPEN-ILS-GENERAL] ***SPAM*** RE: ***SPAM*** Serial Module - Development Direction

[Marjolein Kremer]

Hi Dan,

We took our time to read and reread your mail about the Serial Module.
Here is our first reaction, also to let you know that we are interested
in the developments of the Serial Module and that we will do our best
to participate in the discussion, though our technical knowhow is, as
yet, not so big.

The IISH  (The International Institute of Social History in Amsterdam)
has  two streams of incoming periodicals :
1.	Subscriptions. We have about 1500 subscriptions  in our present
Serial Module (Advance ILS  and migrating to Evergreen later this year),
in which we control the predictions, receiving, claiming and so on. We
would like to continue this.
2.	 Periodicals we receive in bulk parts. They arrive at the
Institute with a collection of books, archive, photos etc.  We have
around 100.000 serial records in the database. These periodicals do not
have to be linked with all the serial management data, they only need a
852 (call number) and a 866 (textual holding).
So actually, we are using and , considering the kind of periodicals we
have,  would like to keep on working in the, as you name it,  the
'conservative' way.

To answer your question : Are visible, editable MFHD records truly
necessary?
Yes, is our answer. Our library gets most of its periodicals by means of
gifts. That means that we always have to edit the (textual) holding. It
also means that with that part of our collection we ONLY need the 852
and the 866 and NOT the other 85x and 86x fields.

Marjolein Kremer



-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Dan Wells
Sent: zaterdag 8 mei 2010 20:12
To: OPEN-ILS-DEV at list.georgialibraries.org;
open-ils-general at list.georgialibraries.org
Subject: [OPEN-ILS-GENERAL] ***SPAM*** Serial Module - Development
Direction

Hello all,

As anyone who follows the IRC channel knows, there has been some healthy
discussion about what exactly we are trying to model with our serials
module. Opinion is starting to solidify around a certain direction, but
I wanted to invite others to please weigh in.

There are at least two distinct ways to approach the problem of serials.
I will label them as 'conservative' and 'progressive', and will attempt
to briefly characterize each approach and also list some corresponding
positives and negatives.

Conservative:
From a conservative perspective, serials management should primarily
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
considerations we are simply missing entirely?

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