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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: >> 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 >
