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 2009

PCCTG1 August 2009

Subject:

Re: NonLatin Documentation report due Monday

From:

"D. Brooking" <[log in to unmask]>

Reply-To:

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

Date:

Tue, 18 Aug 2009 12:20:42 -0700

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (290 lines)

Correct me if I am wrong, but this is another case where it wouldn't hurt 
to be very explicit. MA in which guidelines? Fields that are mandatory if 
applicable in CONSER or BIBCO standard records, or fields that *our* 
non-Latin guidelines list as MA?




************
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 Tue, 18 Aug 2009, Fletcher, Peter wrote:

> On the record characteristics issue (parallel field or not),this could
> be the wording:
>
> All non-Latin data for fields listed as MA (mandatory if applicable)
> must have an equivalent (parallel) romanized element, and all headings
> must be established in Latin according to AACR2, whether or not they
> have a parallel non-Latin field.
>
>
> Peter
>
> -----Original Message-----
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On
> Behalf Of David W Reser
> Sent: Tuesday, August 18, 2009 8:12 AM
> To: [log in to unmask]
> Subject: Re: [PCCTG1] NonLatin Documentation report due Monday
>
> Thanks, Robert-- there is no requirement to pair fields other than the
> MA fields.  Although ubiquitous in LC monograph records, CONSER records
> seem to use the unpaired fields with non-Latin script primarily for
> "description based on" notes.
>
> Dave
>
>>>> Robert Rendall <[log in to unmask]> 8/18/2009 10:59 AM >>>
> Peter -
>
> Thanks for pulling this together.
>
> I still think the first statement under 1. Record characteristics is
> wrong.  According to Dave in Googledocs LC is adding original-script
> "optional" fields like a 505 to a record without providing
> romanization.
>
> I think the Masahiko example should be:
> ___________
> 500   ?a Editor: ????
> 500   ?a Editor: Aoki Masahiko
>
> Not:
>
> 500   ?a ??: ????
> 500   ?a Editor: Aoki Masahiko
> ___________
>
> That's the likely misinterpretation that we're trying to prevent.  Of
> course ??:Aoki Masahiko would be wrong too, but that's just absurd
> (cataloging language Japanese with romanized transcription).
>
> I'll revise my suggested text under the single-780 example to spell
> things out even more: [No parallel field; related record is romanized
> only].
>
> Robert.
>
> Fletcher, Peter wrote:
>>
>> I have made   the editing suggestions from everyone, including
>> updating the report document. I have done the best I can with scripts
>
>> that are unfamiliar to me, and it is a real nightmare having
>> bi-direction of scripts in one document, at least for me. We should
>> have more time to work on the final report and the language experts
>> can again go over it with a fine-tooth come. A problem is formatting:
>
>> It is possible that each of us are seeing something a little
>> difference and may have different versions of Word. Also, I'm
> learning
>> about bi-directionality and how to format it in a Word document, and
>
>> it is problematic: the Arabic or Hebrew words may get switched around
>
>> and I wouldn't know about it!!
>>
>>
>>
>> after I submit our report (probably tomorrow, Tuesday now), I'll
>> repost it on Google docs as a new document and we can go about
> working
>> on our special sections.
>>
>>
>>
>> I am having a sinking feeling on the issue about including special
>> rules for some languages such as Hebrew or Arabic: specifically that
>
>> it will be difficult to form agreement within those communities.
>> Perhaps our Hebrew or Arabic experts can weigh in on that? In OCLC
> and
>> among PCC and LC catalogers I have noticed a wide range of practice
> in
>> the name headings*some without the qualifiers, some with translated
>
>> qualifiers, etc., etc., etc.
>>
>>
>>
>> I have attached the revised documents. Sorry they are not color coded
>
>> or with track changes. See Robert's email below and also I
> corrected
>> the Russian examples and did my best to correct the Yiddish and
> Arabic
>> text. The Greek special section is gone also for now. I also added,
> on
>> the 1^st page, what the MARC-8 consists of, specifically.
>>
>>
>>
>> Peter
>>
>>
>>
>> *From:* Program for Cooperative Cataloging [mailto:[log in to unmask]]
> *On
>> Behalf Of *Robert Rendall
>> *Sent:* Monday, August 17, 2009 10:52 AM
>> *To:* [log in to unmask]
>> *Subject:* Re: [PCCTG1] NonLatin Documentation report due Monday
>>
>>
>>
>> Comments on these drafts:
>>
>> Discussion issues:
>>
>> One more con against recording non-Latin variants only in the
>> authority record: original-script headings serve a display purpose as
>
>> well as an access purpose.  They can provide a more prominent
>> original-script display of e.g. an author than the corresponding text
>
>> in the statement of responsibility.  And in some records (CSR
> records)
>> the statement of responsibility may not be transcribed at all, in
>> which case a parallel heading field is the only place where the name
>
>> can be provided in original script for users unfamiliar with
> romanization.
>>
>> Draft guidelines:
>>
>> 1: the statement "all non-Latin data provided in a PCC MARC record
>> must have an equivalent ..." is apparently not entirely accurate -
> see
>> the most recent comments in Googledocs.
>>
>> 2.2: delete the comma after "provide."
>>
>> 2.3: the last letter (*) of the Yiddish-script subtitle is missing.
>>
>> 2.3: the indicators of the 245s for the Arabic example should both be
>
>> either 00 or 10
>>
>> 2.3: I think it's confusing to suddenly throw in an 880 example here
>
>> when we're talking about something else.  I would be consistent about
>
>> how all the examples appear in the main text of the guidelines, and
>> put an example of 880 vs. parallel display up in the introduction if
>
>> we think it's necessary.
>>
>> 2.4: in the "but not" example the second line should be: 500 $a
>> Editor: Aoki Masahiko; the point is that you don't translate "editor"
>
>> into Japanese in the parallel field above.
>>
>> 2.5: culturally it seems a little strange to provide a parallel field
>
>> for the Chinese Communist Party in traditional rather than simplified
>
>> characters but maybe the book being cataloged was published in
> Taiwan...
>>
>> 2.6: if we're going to go with this guideline, we should provide an
>> example with a romanized field only and then say underneath [linked
>> record does not have non-Latin script data] to make it clear what
>> we're talking about.
>>
>> 3.3.1: aren't macros usually used to generate the original script
>> rather than the transliteration?  I would just say: "If macros are
>> used, manual editing may be required."
>>
>> 3.4: some of the Greek text got italicized, and the bib. record
> fields
>> would need MARC tags, but we should omit this whole section for now.
>>
>> Robert.
>>
>>
>>
>> Fletcher, Peter wrote:
>>
>> All,
>>
>>
>>
>> I have attached a */preliminary /*report and a current version of our
>
>> document incorporating as far as possible most  of your suggestions.
> I
>> need to send this to Joan Schuitema, chair of SCS, on Monday.
> Remember
>> we just need to get something in to show our progress and elicit some
>
>> feedback, so this is far from the final version. The special script
>> section is listed as [UNDER CONSTRUCTION], since we need to resolve
>> the issue of allowing exceptions to the CEG appendix standards, and
> we
>> need to flesh this section out with more possible examples regardless
>
>> of whether or not they are exceptions.
>>
>>
>>
>> The report lists two issues for discussion to elicit feedback: 1.
>> allowing exceptions from the CEG standards for certain
>> languages/scripts; 2. placing non-Latin data only in authority
>> records. Do we all agree on bringing these issues up?
>>
>>
>>
>> Also, David thinks it might be necessary to indicate explicitly the
>> current MARC-8 character set, rather than just state "current
>> character set and leave it at that. Any further thoughts on that?
>>
>>
>>
>> Finally, David was unclear about the problems with the Greek
> character
>> set. Is there any resolution on that issue? Do we still need the
>> special rule in the Greek section?
>>
>>
>>
>> Sorry there is not much time for feedback, but it has been a busy
> time
>> and as I said, this is not a final version but a preliminary report.
>>
>>
>>
>> Peter
>>
>>
>>
>> Peter Fletcher
>>
>> Cyrillic Catalog Librarian and Metadata Specialist
>>
>> [log in to unmask] <mailto:[log in to unmask]>
>>
>> Office: (310) 206-3927
>>
>> Fax: (310) 794-9357
>>
>> UCLA Cataloging & Metadata Center
>>
>> 11020 Kinross Avenue
>>
>> Box 957230
>>
>> Los Angeles, CA 90095-7230
>>
>>
>>
>>
>>
>

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