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??).
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. Stuart Miller -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Scott Sent: Saturday, September 13, 2008 8:25 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management Hi Stuart: 2008/9/11 Stuart Miller <[EMAIL PROTECTED]>: > I'd like to point out that while I would very much like to think > prediction is no longer necessary, the fact is that nearly half of our > active serial subscriptions are still print--and that's after > cancelling print wherever we could for the electronic versions. We > will be stuck for yet many more years with managing something like > 20,000 print subscriptions. If anyone can figure out how we can > maintain one key-stroke checkin and monitor claims WITHOUT prediction, > we're all ears. I just don't think abandoning checkin and claiming for > THAT many titles is possible--much as I would like to recommend it. > That isn't to say we couldn't manage those print serials in some > existing, proprietary stand-alone system and pull holdings data into > a public interface, but I think this library (and other ARLs probably) > would like to have usable serials control in an open source ILS. But > given the cost of replicating prediction features (and who really wants > to code that AGAIN?) and the fact that so many libraries CAN ditch > prediction because the number of print subscriptions is so small anymore, > I'm doubtful if ANY open source ILS is going to meet serials management > needs like ours--unless of course the big libraries are willing to > develop the needed functions. Such a thought gives me hives, but we > might end up having no other choice. All the "choices" we have at the > moment are most unappealing when it comes to serials. For what it's worth, some work is underway in Evergreen towards supporting print serials with predictions and claiming via MFHD. We've all been pretty focused on finalizing the 1.4 release for some time now, though, so there hasn't been much visible progress on the serials front. Can you be more explicit about the kinds of support a library like yours needs for serials management? Subscription renewals, holdings statements (generated or manual textual summaries?), predictions, and claiming? Most of us have no idea what it's like to work at an institution with 20,000 print serials. -- Dan Scott Laurentian University
AcqSerialsRequirments.doc
Description: AcqSerialsRequirments.doc
