Email list hosting service & mailing list manager

(Previous discussion continued)
Re: ANSI Level 4 compressed Kevin Randall (05 Aug 1994 19:25 UTC)

Re: ANSI Level 4 compressed Kevin Randall 05 Aug 1994 19:25 UTC

On Wed, 3 Aug 1994 15:08:15 EST Kathleen A Peterson said:

>The first question was how to describe a volume that comprises only part of a
>year, like Newsweek which is published in 2 vols. a year. The options were:
>        v.107 (1986:Jan.-June) or v.107 (1986:Jan./June)
>Susan replied that they would simply use v.107 (1986). This is addressed in
>the standard in 8.3.2, which states:
>       If within a level there are no gaps, enumeration/chronology data can be
>       further compressed to eliminate an unnecessary, subordinate level of
>       detail. For example: v.1:no.1 (1976:Jan.)-v.1:no.12 (1976:Dec.) would
>       become: v.1 (1976).

Isn't the word "unnecessary" important here?  I wouldn't consider the months
to be an unnecessary subordinate level of detail if the sum of that level
doesn't EQUAL the next higher level.  In the Newsweek example above, v. 107
comprises only half of 1986, not the entire year; it takes both v. 107 and
v. 108 to make up the whole of 1986.

>On the second question, regarding a volume comprised of >1 issue which covers
>a noncalendar year, would you use: v.1 (1993:July-1994:June), or v.1
>(1993:July/1994:June), or v.1 (1993/1994). Susan said to use the 3rd option,
>but felt that the 2nd might be correct too, mentioning that this question
>might be open to interpretation at the local level. (Susan, I hope I'm not
>misrepresenting your statements).  This is addressed in the standard in
>, example (3):
>        A diagonal (/) shall be used as a separator if the chronology data for
>        a single bibliographic unit spans a noncalendar year or more than one
>        year. For example:  1969/1970- [for a noncalendar date or biennial],
>        1980/1982, [for a triennial publication].

I agree that both of the "slashed" options seem to be able to fit into
interpretations of the standard.  I think I prefer the more "complete" one
(1993:June/1994:July) over the other one, even though it does take up 10 more
characters...  I definitely want to compress, but I don't like the idea of
losing information in the process; "1993/1994" is rather ambiguous--it could
mean anything from "Jan. 1, 1993-Dec. 31, 1994" to "Dec. 31, 1993-Jan. 1,
1994"!  (Well, context does add something, I suppose; surrounding statements,
knowledge of the periodical itself, etc. will explain some things.)

>As to the 3rd question regarding microform holdings, I can't find anything in
>the standard either relating to this question, but again concur with Susan in
>using v.1:no.1 (1993:Jan.)-v.1:no.6 (1993:June), so that there is parallel
>construction on either side of the hyphen.

I think I agree here too.  Basically, we should just record the holdings in
terms of the original publication...

>Hope this is of help to you, Kevin (and other interested subscribers). I find
>myself going back to the standard often, especially since we use different
>levels of holdings statements for our OPAC and for union listing. For our
>library has statements in the OPAC, we use level 4 detailed holdings, except
>that our lib has statements in checkin records are left open-ended. For LDR's
>reported to OCLC we use level 3 (summary) holdings. Again, Susan, I apologize
>if I misrepresented any of your statements.

In discussing the matter of compressed vs. noncompressed holdings in check-in
records, we decided not to follow the ANSI standard.  We use the NOTIS O/P/R
record for check-in, and the space is too limited to allow a true Level 4
compressed statement.  We could go the detailed route, putting each piece in
a separate line, but then there's the problem of NOTIS limiting the OPAC
display to 15 lines of receipt data...  So we're going to be using a variation
of our current practice, adding capitalization and punctuation from the ANSI
standard.  For example:  v.1:no.1-8(1994:Jan.-Aug.)    If and when we get a
serial check-in system that uses the USMARC paired fields AND interfaces well
with the other modules of the online system, we may be able to consider
recording new receipts as individual items.

Thanks for the responses to my questions.  There hasn't been a whole lot of
discussion, but all of the responses have helped me think through the issues.
I'm wondering--are there a lot of libraries that have still not adopted the
ANSI standard?

Kevin M. Randall
Northwestern University Library