LISTSERV mailing list manager LISTSERV 16.0

Help for PCCTG1 Archives


PCCTG1 Archives

PCCTG1 Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

PCCTG1 Home

PCCTG1 Home

PCCTG1  August 2013

PCCTG1 August 2013

Subject:

Re: cm and csr

From:

Kevin M Randall <[log in to unmask]>

Reply-To:

Program for Cooperative Cataloging <[log in to unmask]>

Date:

Mon, 26 Aug 2013 23:14:01 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

EXCELLENT rundown of the arguments in favor of retaining the core-ness of the series statement, Chris!

Thank you!!

Kevin

P.S.  While we may have left the 440 to "float gently", my wish was to tie it to a concrete block and let it sink to the bottom.


> -----Original Message-----
> From: Program for Cooperative Cataloging
> [mailto:[log in to unmask]] On Behalf Of CHRISTOPHER WALKER
> Sent: Monday, August 26, 2013 6:06 PM
> To: [log in to unmask]
> Subject: Re: [PCCTG1] cm and csr
> 
> Colleagues,
> 
> As God is my witness </Georgia accent> I will never comment again
> about the damned period.
> 
> I don't favor any development of a flow-chart approach
> to deciding whether or not the cataloger should record the series
> statement,
> depending on whether or not s/he is going to enter an authorized access
> point in an 8xx field.
> 
> 1) As a trainer, I think this approach is unwieldy.
> 2) That's more or less what the 440 was for, and we cast that adrift to float
> gently
> to the shore of the Island of Lost Toys.
> 3) Most significantly, we have colleagues in institutions where series work
> is discouraged,
> who are not even supposed to cross-check in LCAF to see if the series they
> see on the piece
> is, or isn't, established. (Don't we?) The CCM has to work for them, too.
> 
> The series statement is CORE (2.12).
> LC-PCC practice says it must be recorded unless,
> in the judgment of the cataloger, the series-like statement they see
> is not a "true series" (that's the LC-PCC PS wording, not mine).
> 
> If the real objection is that the 490 is redundant when it matches the
> series access point,
> I'm sorry, the objection that a descriptive element is redundant was buried
> in the back yard
> with no headstone, when we began insisting on repetitive 588s citing
> first-seen and last-seen issues
> that duplicate the information in the 362. That novelty was cited and sold
> as a training issue.
> 
> Finally, as serialists, we know that the series statement and the authorized
> access point for it
> quite often will diverge as more issues come to hand.
> Recording the series statement is important for the identification of the
> resource
> and the identification of the best surrogate record for it.
> 
> 
> Christopher H. Walker
> Serials Cataloging Librarian
> Penn State's representative to the CONSER Operations Committee
> Member at Large, ALCTS CRS Executive Committee 2013/2016
> 126 Paterno Library
> The Pennsylvania State University
> University Park, PA 16802-1812
> (814) 865-4212
> [log in to unmask]
> 
> 
> 
> ----- Original Message -----
> From: "Eugene H Dickerson" <[log in to unmask]>
> To: [log in to unmask]
> Sent: Monday, August 26, 2013 3:43:50 PM
> Subject: Re: [PCCTG1] cm and csr
> 
> 
> I neglected to comment on Kevin’s point about the series statement. I
> think that we should consider changing the policy statement to make
> recording the series statement (MARC field 490) optional if the cataloger
> is making an authorized access point for the series (assuming that the
> form of the series title on the resource is the same as the authorized
> access point or is reflected in the series authority record as a variant
> access point). If the cataloger chooses not to make an authorized access
> point for the series (for example, the library’s policy is not to create series
> authority records), then the cataloger should record the series statement
> as it appears on the resource (use MARC field 490). I believe that this is
> the same as the CONSER Standard Record policy. I was just reiterating it.
> 
> Thanks,
> 
> Gene
> 
> Eugene Dickerson
> Lead Librarian for Cataloging
> Ralph J. Bunche Library
> U.S. Dept. of State
> 2201 C Street NW, Rm. 2438
> A/GIS/IPS/LIBR
> Washington, DC 20520
> (202) 647-2191 voice
> [log in to unmask]
> 
> 
> From: Program for Cooperative Cataloging
> [mailto:[log in to unmask]] On Behalf Of Dickerson, Eugene H
> Sent: Monday, August 26, 2013 2:25 PM
> To: [log in to unmask]
> Subject: Re: [PCCTG1] cm and csr
> 
> Hi, Kevin.
> 
> 
> I agree with everything you’re saying in your “rant”. We should either
> make the guideline ALWAYS add the period or NEVER add the period. (I
> vote for NEVER.) I think we should have stopped coding ISBD punctuation
> completely with the implementation of RDA, but I guess people just
> couldn’t let it go. (Robert Bremer made a great case for not coding ISBD
> punctuation in OCLC MARC records, but the RDA “powers that be” didn’t
> embrace the idea.)
> 
> 
> We need to focus on the description and subject analysis when creating
> or maintaining records and not spend time agonizing over punctuation.
> 
> 
> Who would have thought that some people would spend even more time
> agonizing about punctuation in RDA than they did in AACR2 (which was
> bad enough)?!
> 
> 
> Gene
> 
> Eugene Dickerson
> Lead Librarian for Cataloging
> Ralph J. Bunche Library
> U.S. Dept. of State
> 2201 C Street NW, Rm. 2438
> A/GIS/IPS/LIBR
> Washington, DC 20520
> (202) 647-2191 voice
> [log in to unmask]
> 
> -----Original Message-----
> From: Program for Cooperative Cataloging [
> mailto:[log in to unmask] ] On Behalf Of Kevin M Randall
> Sent: Monday, August 26, 2013 1:57 PM
> To: [log in to unmask]
> Subject: Re: [PCCTG1] cm and csr
> 
> Area 6 was never "kaput" in CONSER. It was turned into an *option* in the
> CSR. (Remember the floor vs. ceiling mantra...) Moreover, that was under
> AACR2, and the status of Area 6 under RDA for CONSER seems to be in
> limbo. The PS for 2.12 currently makes no mention at all of the series
> statement being optional for serials. This is an apparent oversight, and is
> something that needs to be resolved.
> 
> <rant>All that being said, I want to reiterate my point that I have made in
> some other discussion lists: the whole period-or-no-period-after-"cm"
> controversy is PROFOUNDLY ridiculous. The PCC policy is based ENTIRELY
> on an assumption that the records are being constructed specifically for
> display in OPACs that are following ***OLD*** ISBD punctuation
> guidelines, AND a specific kind of ISBD display (starting a new paragraph
> with Area 7). The current ISBD Consolidated Edition clearly says that
> there's going to be a period at the end of Area 5 regardless, according to
> A.3.2.3: "Each area of the description other than the first is preceded by a
> point, space, dash, space (. - ), unless that area is clearly separated from
> the preceding area by paragraphing, in which case the point, space, dash,
> space may be replaced by a point (.) given at the end of the preceding
> area." We should either say NEVER use a period after "cm" (because it's a
> symbol, not an abbreviation), or say ALWAYS use a period after "cm"
> when it's the end of the 300 field, because it's the end of an area. But of
> course, inconsistency is rule number one when it comes to putting ISBD
> punctuation into MARC records...</rant>
> 
> Kevin
> 
> > -----Original Message-----
> > From: Program for Cooperative Cataloging
> > [ mailto:[log in to unmask] ] On Behalf Of Ed Jones
> > Sent: Saturday, August 24, 2013 7:40 PM
> > To: [log in to unmask]
> > Subject: Re: [PCCTG1] cm and csr
> >
> > Adolfo
> > Here is my thinking: I suppose a program could ingest such a record
> > and display the data in the 8XX field in area 6 for serials and
> > ongoing integrating resources (but not monographs or "monographic"
> > integrating
> > resources) or create a duplicate 4XX when these conditions applied,
> > but does any program do so? And why develop such a program rather
> than
> > just cutting-and-pasting the 8XX into the 4XX if a display of area 6
> > is desired?
> >
> > Also we would have to acknowledge not all libraries have such
> > systems-- mine doesn't anyway--so recording the period in a particular
> > case would become contingent on whether or not your library's system
> > did so, rather than on a general principle.
> >
> > It's better, I think, to assume the rumors are true, and our systems
> > are fairly primitive in such matters. When CONSER decided to record
> > series only in 8XX, we implicitly got rid of area 6 of the description.
> >
> > Assuming that area 6 is kaput in CONSER records has the added
> > advantage that we avoid the agony of having to calculate whether or
> > not to add the point in any given case, and can consequently watch
> > with equanimity as our monographic brethren struggle with this
> > question again and again. :-)
> >
> > Ed
> >
> > Sent from my iPhone
> >
> > On Aug 24, 2013, at 14:33, "Tarango, Adolfo" < [log in to unmask] >
> > wrote:
> >
> > > Is that really the case? True, we aren't recording the series
> > > statement in
> > a 4XX field, but the resource presents us area 6 data. It's just that
> > when recording the series statement following CSR practice and using
> > the MARC format, we choose to record the series statement only in an
> > 8XX field when the authorized form and the form on the piece are the
> same.
> > Isn't this really a data "output" question: in cases where we record
> > the series statement only in an 8XX, does the series statement "print"
> > or "display" as area 6 data? If so, then the point is needed.
> > >
> > > Adolfo
> > >
> > > -----Original Message-----
> > > From: Program for Cooperative Cataloging
> > [ mailto:[log in to unmask] ] On Behalf Of Ed Jones
> > > Sent: Saturday, August 24, 2013 9:25 AM
> > > To: [log in to unmask]
> > > Subject: Re: [PCCTG1] cm and csr
> > >
> > > Beth
> > >
> > > You are correct. The period is part of the "point-space-dash-space"
> > prescribed punctuation that precedes the series area (area 6) in the
> > description. Since there is no area 6 in these circumstances, there is
> > no preceding prescribed punctuation, and hence no period.
> > >
> > > The dash can be supplied by program on output, and theoretically--
> > since RDA removes the period that formerly followed "cm" under
> AACR2--
> > the whole "point-space-dash could have been supplied by program on
> > records coded $e rda, obviating the need for that part of your chart.
> > Maybe some day...
> > >
> > > Ed
> > >
> > > Sent from my iPhone
> > >
> > > On Aug 24, 2013, at 8:11, "Beth Thornton" < [log in to unmask] > wrote:
> > >
> > >> Hi everybody,
> > >>
> > >> I'm working on a little chart which may or may not become part of
> > module 21. Well actually I have been working on a chart and today I
> > sat down to revise some cataloging I did. It was a bare-bones record
> > so I converted to RDA. And upon looking again I realized that I forgot
> > to delete the period after cm. No series statement.
> > >>
> > >> So I went back to my chart to add that, because there are, maybe,
> > people like me, who might need a reminder. I know that if there is a
> > series statement, then the period is retained because it's isbd
> punctuation.
> > >>
> > >> What if it's a CSR record and the series on the piece is the same
> > >> as the
> > authorized form and so is only given in an 8xx field?
> > >>
> > >> My feeling is that in that case there is no series statement in the
> > record, and therefore no period.
> > >>
> > >> Correct? Way off base?
> > >>
> > >> Long-windedly yours,
> > >> Beth
> > >> UGA
> > >>
> > >> --
> > >> Beth Thornton
> 
> 
> 
> 
> 
> This email is UNCLASSIFIED.

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
August 2019
July 2019
May 2019
April 2019
February 2019
January 2019
December 2018
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
October 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
December 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
February 2003
June 2001
January 2001
December 2000
November 2000
October 2000
September 2000
July 2000

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager