We have been trying to enumerate serials holdings as explicitly as possible. E.G., this microfiche supplement to a journal, http://summit.syr.edu/cgi-bin/Pwebrecon.cgi?BBID=274291 shows apparently missing issues. However, there are two pieces of inferred information here:
1) every print issue had a corresponding microfiche supplement (they didn't, so most of these are complete even with the "gaps") 2) that volumes, at least up until 1991, had only 26 issues (that is probably is true, but it is not certain) and there is no way to be certain how many issues per volume were published with 1992 (28?, 52?) v.95:no.3 (1973)-v.95:no.8 (1973 v.95:no.10 (1973)-v.95:no.26 (1973) v.96 (1974)-v.97 (1975) v.98:no.1 (1976)-v.98:no.14 (1976) v.98:no.16 (1976)-v.98:no.26 (1976) v.99:no.1 (1977)-v.99:no.25 (1977) v.100 (1978)-v.108 (1986) v.109:no.1 (1987)-v.109:no.19 (1987) v.109:no.21 (1987)-v.109:no.26 (1987) v.110 (1988)-v.111 (1989) v.112:no.1 (1990)-v.112:no.26 (1990) v.113 (1991) v.114:no.1 (1992)-v.114:no.21 (1992) v.114:no.23 (1992)-v.114:no.27 (1992) v.115 (1993)-v.119 (1997) v.120:no.2 (1998:Jan.21)-v.120:no.51 (1998:Dec.30) On Tue, Jun 15, 2010 at 9:56 PM, Bill Dueber <b...@dueber.com> wrote: > On Tue, Jun 15, 2010 at 5:49 PM, Kyle Banerjee <baner...@uoregon.edu> > 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 >
