[OPEN-ILS-GENERAL] RE: Serials Management

[Frances Dean McNamara]

That's a good idea.  I have seen a number of systems where people started up serials checkin and every single institution had to set up patterns even though they were really the same for everyone.  For this ISSN, the pattern is whatever.  Good idea to think of that during design because it turns out to be a huge waste of time for every site to have to set that up themselves, manually for every title.

I'll let Stuart answer about exporting patterns from Horizon.  I forget if there's a way.  Maybe somebody else on the list knows, too.

Frances McNamara
University of Chicago

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

Stuart,

I have just started working on code to read MFHD records, and I can
tell you that the pattern stuff in the standard is pretty expressive.
But the more real-world examples we can get our hands on, the better.

Does Horizon provide some other format for exporting / importing
holdings data, even if it's only for sharing with other Horizon
systems?

I have started to think that serials issuance patterns are something
that should be shared: it's not like I get different issues of the
Economist or Lancet than you do, so why should we duplicate the effort
of describing the pattern?

That is, of course, a completely different project from
exporting/importing holdings data and making predictions about when
the next issue should arrive.

On Tue, Sep 16, 2008 at 3:19 PM, Stuart Miller <stuartwm at uchicago.edu> 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
>