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

PCCTG1 June 2009

Subject:

Re: Shi's version [FW: Draft derived from CONSER Appendices attached

From:

"Deng, Shi" <[log in to unmask]>

Reply-To:

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

Date:

Sun, 28 Jun 2009 11:00:44 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (212 lines)

Please see my comments started with SD--. And please correct me if I am
wrong. Thanks, --Shi

-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On
Behalf Of David W Reser
Sent: Thursday, June 25, 2009 12:19 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Shi's version [FW: Draft derived from CONSER
Appendices attached

I'll pile my comments in below, prefaced by "DR: ".  Part of my comment
has to do with the assumption stated in Peter's document that I would
have a quibble with-- the assumption that the context is OCLC Connexion.
I don't think that assumption can play well with the PCC's goals of
trying to expand membership beyond the US community (there was a PCC
task group report in the last few years from an internationalization
perspective that I can't cite right this minutes, as well as PCC
confirmation of the expansion of contribution recommendations in the
Future of Bibliographic Control). I know it is easier to do it in the
context of OCLC, especially as the base model started out as a CONSER
doc that had that assumption, but I think we have an obligation to state
things more broadly.  Given the importance of OCLC as a place of
input/edit for so many PCC libraries, as well as a union catalog for
many/most (but not all) PCC records via batch load, I would be happy if
the document provided some OCLC specifics after a more general
statement.

Dave

SD--  Thanks, Dave. When I read Keiko's comments on not mention the
operative environment, I wondered if we leave OCLC out, how would we
address our current practice that has to do with OCLC. Your suggestion
on separating general instruction and OCLC specifics is perfect
solution. It addresses what we need in current environment and also
opens up possibilities for future from internationalization perspective.
I am easily convinced on this one.

>>> Robert Rendall <[log in to unmask]> 6/25/2009 2:45:08 PM >>>
More comments below.

Robert.

D. Brooking wrote:
>
> Comments below.
>
>
>
> ************
> Diana Brooking             (206) 685-0389
> Cataloging Librarian       (206) 685-8782 fax
> Suzzallo Library           [log in to unmask] 
> University of Washington
> Box 352900
> Seattle WA  98195-2900
>
> On Wed, 24 Jun 2009, Deng, Shi wrote:
>
>>
>> I forgot to mention that in CONSER appendix E&O, there are general 
>> guidelines that was not incorporated by Peter?s draft yet that I
listed
>> below, also in the draft I put together. These are very practical 
>> instruction and general principles that I think we should incorporate
>> into Peter?s draft section one. I didn?t add to the Google document, 
>> but want to bring to your attention. Thanks. --Shi
>>
>>  
>>
>>  1. PCC participants may choose to authenticate English records 
>> containing non-Latin script (i.e., CJK, Arabic, etc) or those that
are
>>     fully romanized, according to their individual institution's 
>> needs or abilities.  However, if an English non-Latin record exists,
a
>>     record that contains only romanized data should not be entered 
>> for the same item.
>>
>
> Probably worth saying, as there is a lot of confusion about parallel 
> records in OCLC right now anyway.
>
>
Here's that phrase "fully romanized" again!  Is it supposed to mean 
"only romanized"? 

I think this is more complicated than it needs to be.  Maybe: "PCC 
participants may choose to authenticate an English record containing 
both romanization and non-Latin script (i.e., CJK, Arabic, etc), or an 
English record containing romanization only.  Only one English record 
may be authenticated for each title.  Non-Latin script may be added to 
existing authenticated records containing romanization only."

DR:  Good start on the concepts, which I agree need to be stated, but
I'd prefer to re-word to be more generally applicable to the PCC at
large:

"PCC participants may choose to create records with a language of
cataloging of English in one of two models:
1. Roman only (i.e., all non-Latin script data is romanized following
the appropriate romanization table, no non-Latin scripts are provided);
or,
2. Roman/romanized and non-Latin scripts in a single record (i.e.,
parallel non-Latin and romanized fields are supplied following the
guidelines in this document).
     PCC participants creating records in OCLC (or loading records to
OCLC) should not create a duplicate roman-only record if a record for
the same manifestation already exists with the language of cataloging in
English containing non-Latin scripts; PCC participants are welcome to
add non-Latin scripts to records on OCLC that are roman only."
 [I'll let Glenn speak to whether this CONSER practice is OCLC's policy
overall for WorldCat-- we can adjust as necessary per his advice] 

SD--  Robert, I was trying to present what was in the existed document
for us to evaluate and/or revise it. And I agree with you about the
phrase as you pointed out. Sometime it's hard for me to question the
existed instruction after being trained to think what it means. And I
get excited to see you and Dave "just do it" by making better proposed
revision. And I like Dave's proposed revision and his action to separate
general statement from OCLC specifics. I hope that you don't mind that I
brave myself to make some minor changes to the term "romanization" or so
in order to line up with RDA from internationalization perspectives.
Also I wonder if we should switch the two models since more libraries
now are capable to record original non-Latin script data. 

"PCC participants may choose to create records with a language of
cataloging of English in one of two models:
1. Transliterated and original non-Latin script data in a single record
(i.e., parallel non-Latin and transliterated fields are supplied
following the guidelines in this document); or,
2. Transliterated data only (i.e., all original non-Latin script data is
transliterated following the appropriate romanization table, no
non-Latin script data are provided).
     PCC participants creating records in OCLC (or loading records to
OCLC) should not create a duplicate transliterated data only record if a
record for the same manifestation already exists with the language of
cataloging in English containing original non-Latin scripts data; PCC
participants are welcome to add non-Latin script data to records on OCLC
that are in transliterated form only."

>>  
>>
>>  1. PCC participants should not create "hybrid" records [s2] (i.e., 
>> records that would qualify as neither "romanized-only" nor as "fully
>>     non-Roman").  If any non-Roman script data is provided, it should

>> be provided for all fields in which it would be appropriate
>>
>
> Peter's draft under in first part: "Although the decision to include 
> data in non-Latin form in any PCC record is strictly optional, when 
> that option is exercised, it must be done so according to these 
> guidelines."
>
> Later on, it says "With some restrictions indicated here, parallel 
> non-Latin data may be created for those fields, parts of fields, or 
> subfields that are romanized according to the accepted standard."
>
> The CONSER formulation is more direct. (Though I still find the 
> explanation in parens to be unclear.) And if we have the chart of what

> is mandatory and what is optional for non-Latin fields in a PCC record

> up higher in the document, then that would reinforce which fields are 
> "appropriate."
>
Re: the wording of the original guideline, I thought we weren't allowed 
to create "fully non-Roman" records in PCC.

I would say: "The decision to include data in non-Latin form in any PCC 
record is strictly optional.  If any parallel fields including non-Latin

data are added to a bibliographic record, they must be added for all the

fields listed as Mandatory (if applicable)."

DR:  Agree.
SD-- Same here. Thanks, Robert. 

>>
>>  1. Give non-Latin data only in the fields specified below and only
when transcribed or derived directly from non-Latin data on the item
>>     being cataloged or from a linked record.
>>
>
>Repeats the idea of providing non-Latin in appropriate fields. The idea
of 
>taking non-Latin from the piece appears in different places in Peter's 
>draft under the specific fields, but it would be a good idea to put it 
>into General guidelines? However, this implies that 1) don't provide 
>non-Latin for cataloger-supplied qualifiers (they aren't on the item)
and 
>2) don't provide non-Latin for headings (since they also may not match
the 
>name on the piece, even if the heading is ALA/LC transliteration).
>
>So I am not sure, especially with regard to headings, if we actually 
>follow this rule? Or does it all depend on the meaning of the words 
>"derived directly" from the item? What *does* that mean, as opposed to 
>"transcribed"?
>
>We may want to rework or reconsider this statement anyway.

SD-- I agree with Diana on the name headings and qualifier, especially
after non-Latin script data added into authority records. If the name
headings are in the form formulated according to ALA/LC Romanization
table, why not to reconsider this statement. But I would exercise
cautiously regarding the linking entry, etc that the above statement
refers in Appendix O. It refers to data taken from a linking record that
is in transliterated form only. And I commented it in Google Doc.

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