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: [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
