[OPEN-ILS-GENERAL] RE: Serials Management

[Stuart Miller]

All too true. We have only a custom MARC holdings export program that John wrote for us.

Stuart Miller

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Jonathan Rochkind
Sent: Tuesday, September 16, 2008 8:06 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management

MFHD is, like many of our library standards, a very BROAD standard.
You can do things lots and lots of ways with MFHD, some very precise,
some not much more than a human readable note.

So I guess that's one reason to be cautious about saying you "support
MFHD" or something. My catalog can export MFHD, but the MFHD it will
export will be almost useless for doing anything at all. (The fault
is a combination of the ILS's and our local practices).  (Horizon
actually can be made to support MFHD with a fairly inexpensive add on
from John Craig (or you can try to write your own), my catalog is
actually Horizon too).

Jonathan


On Sep 16, 2008, at 3:19 PM, Stuart Miller wrote:

> Dan,
>
> This may be an issue of semantics. When I hear someone say that
> they are going to use MFHD to express pub patterns to generate
> predictions, I think "records of variable length fields are NOT
> good candidates for something like prediction." If you're talking
> about Evergreen being able to import pattern data from an MFHD
> file, that's something else. And yes, we can probably export our
> pattern data in MFHD but that will be a custom program we'll need
> someone to write. Horizon never supported MFHD, and now never will.
> Unicorn and other ILS products may indeed be a different story.
>
> But of course getting patterns is only half the battle. The other
> one is writing the prediction algorithms to interpret the plethora
> of patterns represented by 20,000+ serial titles. We have patterns
> of the "every other alternate month when the moon is the 7th house,
> the 3rd issue of the then current volume combines with the 4th
> issue and that issue has only mm/yyyy, not mm/d/yyyy as usual and
> we only have 3 issues per volume instead of 4" type. [I'm only half-
> joking, unfortunately.]
>
> Stuart Miller
>
> -----Original Message-----
> From: open-ils-general-bounces at list.georgialibraries.org
> [mailto:open-ils-general-bounces at list.georgialibraries.org] On
> Behalf Of Dan Scott
> Sent: Monday, September 15, 2008 10:08 AM
> To: Evergreen Discussion Group
> Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management
>
> 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