Don't forget inconsistent data from the person sending the OpenURL.
Rosalyn
On Tue, Jun 15, 2010 at 9:56 PM, Bill Dueber <[log in to unmask]> wrote:
> On Tue, Jun 15, 2010 at 5:49 PM, Kyle Banerjee <[log in to unmask]> wrote:
>> No, but parsing holding statements for something that just gets cut off
>> early or which starts late should be easy unless entry is insanely
>> inconsistent.
>
> And....there it is. :-)
>
> We're really dealing with a few problems here:
>
> - Inconsistent entry by catalogers (probably the least of our worries)
> - Inconsistent publishing schedules (e.g., the Jan 1942 issue was
> just plain never printed)
> - Inconsistent use of volume/number/year/month/whatever throughout a
> serial's run.
>
> So, for example, http://mirlyn.lib.umich.edu/Record/000045417/Holdings#1
>
> There are six holdings:
>
> 1919-1920 incompl
> 1920 incompl.
> 1922
> v.4 no.49
> v.6 1921 jul-dec
> v.6 1921jan-jun
>
> We have no way of knowing what year volume 4 was printed in, which
> issues are incomplete in the two volumes that cover 1920, whether
> volume number are associated with earlier (or later) issues, etc. We,
> as humans, could try to make some guesses, but they'd just be guesses.
>
> It's easy to find examples where month ranges overlap (or leave gaps),
> where month names and issue numbers are sometimes used
> interchangeably, where volume numbers suddenly change in the middle of
> a run because of a merge with another serial (or where the first
> volume isn't "1" because the serial broke off from a parent), etc.
> etc. etc.
>
> I don't mean to overstate the problem. For many (most?) serials whose
> existence only goes back a few decades, a relatively simple approach
> will likely work much of the time -- although even that relatively
> simple approach will have to take into account a solid dozen or so
> different ways that enumcron data may have been entered.
>
> But to be able to say, with some confidence, that we have the full
> run? Or a particular issue as labeled my a month name? Much, much
> harder in the general case.
>
>
> -Bill-
>
>
> --
> Bill Dueber
> Library Systems Programmer
> University of Michigan Library
>
|
