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