[OPEN-ILS-GENERAL] RE: Serials Management

[Dan Scott]

2008/9/15 Stuart Miller <stuartwm at uchicago.edu>:
> I know that 1.4 and 2.0 will introduce support for MARCH Holdings format. I had not heard that anyone was looking at using it for claims or predictions and if that's true, I am very dubious--the only system that I know of that actually built serials management on MARC holdings was the old NOTIS LMS--and even the product manager who designed it admitted that basing it on MARC was, in the end, a bad idea. I believe all other ILS products just constructed their own algorithms and I don't think most of them even got around to exporting the data in MARC (except some did export summary holdings, I think--we can, but only with a custom program from a consultant; the vendor never supplied one, presumably due to lack of demand??).
>

Stuart - wow, that's a pretty negative set of statements.

Just to ensure that we're talking about the same thing here, the idea
was to use MFHD primarily to express publication patterns
(enumerations and chronology), so that one can generate predictions.
We were also planning on being able to export MFHD and to generate
compressed or uncompressed holdings displays.

One assumption is that those using serials management today will be
able to export publication patterns in MFHD from their legacy system
that we can then migrate into Evergreen without painfully recoding
every pattern. Unicorn, for one, does support MFHD export for serials
patterns (at least I _think_ it does; now you've got me wanting to go
back and see whether it's simply regurgitating whatever is in the
85x/86x fields in the bib record - curse you!). I'm sure you wouldn't
want to recode 20,000 publication patterns for your serials; is there
a better alternative than MFHD for serials patterns and holdings
information that you have in mind for an intermediate format? Maybe
sets of cron patterns are the answer for a lingua franca
(http://open-ils.org/dokuwiki/doku.php?id=acq:serials:patterns - he
says, half jokingly).

Another assumption is that staff would be shielded from most of the
complexity of manipulating MFHD patterns by a nice user interface.

Also, MFHD support isn't planned until 2.0. We don't want to get hopes
up too high for the 1.4 release!

Of course, all of this is subject to actually getting some code on the
ground and running through some real data.

> I really can't, in an email, detail the complexities of managing thousands of print serials that run the gamut from very vanilla to very complex enum/chron patterns. I've attached a statement of baseline acq/serials requirements that we developed inhouse for use in evaluating systems. It doesn't get into a lot of details, but it may be of some interest.

Yep, it's certainly of interest. If you can generate a list of the
serial patterns in use at your institution to contribute to the data
that we have collected from Laurentian and Windsor, that would be
useful information too.

-- 
Dan Scott
Laurentian University