Print

Print


Good. Sorry about it. --Shi

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Fletcher, Peter
Sent: Tuesday, May 18, 2010 3:23 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Post PCC OpCo addendum to report; PCCNonLatinGuidelinesReportApr29.doc

Shi, actually the guidelines got renumbered in the final draft: the general section (including headings) to 1., and the special language section to 2.

Peter

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Deng, Shi
Sent: Monday, May 17, 2010 6:13 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Post PCC OpCo addendum to report; PCCNonLatinGuidelinesReportApr29.doc

Thanks to Peter for the update on the feedback from PCC CoOp meeting in the Addendum to report. I understand the concern about having optional practice, but I also agree with what Robert said below. And I like Robert's suggestion and wordings Peter and Robert worked on. Hope the upcoming LC survey would be helpful in deciding about the optional practice. In the worst scenario, if 2.5.2 was removed, I hope it is still documented to give flexibility, so  a library who choose this optional practice doesn't have to code the record pcc, and others would accept and not conform such records to standard practice by deleting these non-Latin data.

By the way, the section number of the guidelines referred in Peter's report section 4 and addendum: should it be changed from 1.5 to 2.5, and from 1.5.2 to 2.5.2?


Thank you. --Shi


From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Robert Rendall
Sent: Monday, May 17, 2010 1:02 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Post PCC OpCo addendum to report; PCCNonLatinGuidelinesReportApr29.doc

And, once that is done, systems that can make intelligent use of that preferred form.  Until then, we need to provide guidelines that will be useful for cataloging in current and near-term future systems, which is what we've tried to do.  In that context, I think what we came up with makes sense enough.

Robert.

Fletcher, Peter wrote:

We did add language strengthening the recommendation that PCC catalogers

add the non-Latin variants to authority records in the guidelines. What

will really solve the problems is arriving at a preferred form of the

name, which we recommend PCC look into.



Peter



-----Original Message-----

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On

Behalf Of Benjamin A Abrahamse

Sent: Friday, May 14, 2010 3:06 PM

To: [log in to unmask]<mailto:[log in to unmask]>

Subject: Re: [PCCTG1] Post PCC OpCo addendum to report;

PCCNonLatinGuidelinesReportApr29.doc



I think we can all agree that "just" documenting practice was no small

feat.  But if our charge was indeed to come up with a standard, then we

should have a standard that makes sense.  Which (to me at least) means

we should push for non-Latin variants of name headings to be added to

authority files, along with all of other variant forms.



--Ben

________________________________________

From: Program for Cooperative Cataloging [[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of

D. Brooking [[log in to unmask]<mailto:[log in to unmask]>]

Sent: Friday, May 14, 2010 5:36 PM

To: [log in to unmask]<mailto:[log in to unmask]>

Subject: Re: [PCCTG1] Post PCC OpCo addendum to report;

PCCNonLatinGuidelinesReportApr29.doc



I see variation in the Cyrillic community as well. Most of it I think is

caused by the technical capabilities of the transliteration macro. That

is, if the whole heading is in a Cyrillic language and the macro can

transform it all, catalogers are reluctant to take the time to go back

and

un-Cyrillicize the qualifiers. Still attempting to impose the standard

in

the case of Cyrillic (or other left-to-right scripts) would not be

unreasonable in my opinion.



And at least some HAPY variation is due to right-to-left technical

difficulties with dates and qualifiers and such. But in those cases,

there

is no way the "standard" can be implemented, right? So maybe those

options

can be moved down to the special languages section of the guidelines.



The real answer lies in authority records and a way to link non-Latin

variants to the controlled heading, for both searching and display. It's

not clear to me if a preferred non-Latin form is necessary for this, but

I

would suspect it would make certain kinds of implementations a lot

easier.



Our report is probably a prime piece of evidence of the trouble you get

into without good authority control mechanisms. PCC Standards should

use this as an opportunity to push that forward.



And I do think our charge was to come up with a standard, not just

document current practice. I remember one thing they were hoping for was

to provide consistency across scripts.





************

Diana Brooking             (206) 685-0389

Cataloging Librarian       (206) 685-8782 fax

Suzzallo Library           [log in to unmask]<mailto:[log in to unmask]>

University of Washington

Box 352900

Seattle WA  98195-2900



On Fri, 14 May 2010, Robert Rendall wrote:





Benjamin A Abrahamse wrote:



Re: "the amount of optionality in the guidelines could be reduced by



making



some of the "optional" practices optional or mandatory for certain



script



groups only", my impression was that we could not do this because



there was



not a one-to-one correspondence between a given script/cataloging



community



and a given "variant practice".  That is to say some cataloging



communities



(particularly HAPY) had more than a single variant in their practice.



Right, but a lot of that variation is pretty much limited to HAPY.  If



we say



everyone else is required to follow the "standard" practice, we'll



eliminate



a lot of optionality right off the bat without making anyone very



unhappy.



The idea of extending HAPY practices to e.g. CJK as an option was



basically a



suggested innovation.  We could back off from that.  And then we could



see if



PCC catalogers within individual HAPY script groups could agree on



single



preferred practices within their own communities.  We can't make those

decisions for them, but we can recommend that they try.



Robert.