LISTSERV mailing list manager LISTSERV 16.0

Help for PCCTG1 Archives

PCCTG1 Archives

PCCTG1 Archives













By Topic:










By Author:











Monospaced Font





PCCTG1  March 2010

PCCTG1 March 2010


Re: Non Latin document final check


"Avetyan, Nora" <[log in to unmask]>


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


Mon, 22 Mar 2010 09:55:31 -0700





text/plain (1 lines)

Dear Ben,

I 2.3 Persian 260 example (p. 4)

[تهران] 260 |a
شهرزاد وقالت 245 |b
سرحان هالة 245 |c
The 245s are in the wrong place and they are in Arabic not Persian, also the word Lebanon Arabic 830 example (p. 10)

(نلبنا ,بيروت) رواية 830 |a is not displayed correctly.

Thank you.


-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Benjamin A Abrahamse
Sent: Friday, March 19, 2010 12:24 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Non Latin document final check

I did my best to fix the Arabic-script examples. I put them into little tables on this Word file; so hopefully it shouldn't be too much trouble to copy-and-paste them into the real document. I did not include ISBD punctuation because I'm not sure whether you wanted to use "upside down" commas, etc., or regular ones. (We seem to be using both at different times in the present document, cf. 2.3 examples vs. 3.1 example.)

I have a couple questions about the Persian example of bad automated transliteration in 3.1.1 (p. 12):

1. Is there a zayin missing in both the incorrect and correct versions of Sadiq'zadah? Its kind of hard to tell because the letters got a little scrambled, but it looks like "Sadiq 'adah" right now.
2. Is there are larger point to this example other than "beware of automatic transliteration"? Could we maybe add a little more explanation?

I also have another question about a Persian example, the example 260 in 2.3 (p. 4). I am not a Persianist, but shouldn’t Tehran be something like تهران ? Or is its Persian name completely different (á la Jerusalem =القد س in Arabic?)

From: Program for Cooperative Cataloging [[log in to unmask]] On Behalf Of Fletcher, Peter [[log in to unmask]]
Sent: Friday, March 19, 2010 2:55 PM
To: [log in to unmask]
Subject: Re: [PCCTG1] Non Latin document final check

Robert, see my comments below.

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Robert Rendall
Sent: Friday, March 19, 2010 7:44 AM
To: [log in to unmask]
Subject: Re: [PCCTG1] Non Latin document final check

Peter -

Thanks for all your work! Some initial comments:

The Arabic, Persian and Yiddish examples will also have to be fixed. The order of the words has been reversed (is that what Sharon fixed for the Hebrew?).

Yes, thanks Robert, Sharon has sent me the corrected Hebrew and Yiddish (I forgot to mention Yiddish).

Translations are not a false problem, we've just sidestepped the issue by giving examples only of translations into English. We still don't have guidelines for translations e.g. from Russian into Hebrew. Probably the parallel 100 and 245 should be in Hebrew script and the 240 with the transliterated Russian original title should just be left unpaired, but I don't think we necessarily have to tackle that now.

Well, with translations from Russian to Hebrew, the parallel non-Latin 130 or 240 should reflect the original language of the title, in this case, Russian, so the principles are the same as for English translations. We need to understand that in these cases, the data cannot be taken from the piece in hand, just as is the case for English translations. By stating that the non-Latin data field must be in the language of the heading (title, name, etc.), it is made clear. Perhaps we can just say “must be in the language of the heading”.

Is this not what we want:

100 1 Достоевский, Фёдор, ǂd 1821-1881. [taken from reference source; not from resource at hand]

100 1 Dostoyevsky, Fyodor, ǂd 1821-1881.

240 10 ǂa Преступление и наказание. ǂl Hebrew [taken from reference source; not from resource at hand]

240 10 ǂa Prestuplenie i nakazanie. ǂl Hebrew

245 11ǂa החטא וענשו : ǂb רומן בששה חלקים עם אפילוג / ǂc פ. מ. דוסטויבדקי ; תרגם י. ח. ברנר.

245 13 ha-Ḥeṭ ṿe-ʻonesho : ǂb roman be-shishah ḥalaḳim ʻim epilog / ǂc F.M. Dosṭoyevsḳi ; tirgem Y. Ḥ. Brener.

Since time is short, and if we cannot agree, I am willing to also state that translations are not covered by our guidelines.

Transliteration is not the same as romanization. The definition we're giving applies to transliteration in general; romanization is specifically transliteration into Latin script.

ok to remove the “synonymous” statement.

I would like to omit the Xun yi cao no chun tian example. It's an example of a cataloger-provided translation (or something), which has nothing to do with what we're talking about in this section.

Which section?

Can we word the recommendation that PCC catalogers add non-Latin variants to authority records more strongly? Maybe "PCC catalogers should also supply ..."

That is fine with me.

The CEG requires that the record linked to should have non-Latin script in it because if it doesn't and you click on your non-Latin linking field in the OPAC you won't get anywhere, even if the other record really is in your catalog and clicking on the romanized linking field would work. I'm not sure what we should say about this.

I am ok with restoring the CEG requirement.

"The headings must be in the language/script of the body, person, or title": we need to think about this more. Otherwise we'll have Cyrillic parallel headings for Russian corporate bodies in Hebrew records, etc. I think current practice is that the headings must be in the script of the title cataloged, except in records for titles in Latin script, where we sometimes provide non-Latin parallel-script fields for non-Latin headings.

I don’t understand. That is what you would want. Russian corporate bodies are established in Russian (i.e., Cyrillic), not Hebrew, so the parallel non-Latin heading will be in Cyrillic, even in a record for a Hebrew translation. If it was a Hebrew body, then it would be in Hebrew script. I know that a lot of Hebraica catalogers may be doing this (e.g. providing Hebrew or Yiddish parallel heading for Russian headings, etc.), but do we want to provide this option?

The special guideline for Arabic script isn't really a special guideline, it's just a general reminder about automatic translation. It seems out of place with the other guidelines that really are talking about script-specific issues. Nora: can this be defined as a problem specifically with the ezafe in Persian?

Under CJK, we haven't addressed Hideyuki's comment that this makes it sound like you shouldn't input spaces between Korean text if there's also a Japanese parallel title somewhere else in the same field.

??? CJK folks?

Under Cyrillic, I would not use the word "added" to describe something that appears on the piece. How about "[soft sign, or whatever] transcribed in original script but not represented in romanization"?

How about this: [ь and ъ transcribed in original script, but not represented in romanization]

I'll send some copy editing suggestions in a Word document with tracked changes later.


Fletcher, Peter wrote:
All, please find attached a close to final draft of our document for PCC non-Latin guidelines in bib. records (good news, it is only 16 pages). Also, will send by tomorrow as attachment the report that goes with it, also in a hopefully nearly final form. [I am enclosing this also as an attachment since some of my formatting may not survive in your emails; hopefully a .doc will preserve the bullets and underlines to make this easier to read]

Please check/keep in mind:

Check your language examples: (I can only check the Cyrillic); especially check the right to left scripts, since I gave up trying to replicate the OCLC right to left (starting from the right hand side of the screen) and some of the letters/words have become reversed, etc. (someone please check the example of the different filing indicators in the Arabic/French title example on p. 4). I added the example in 2.5.1. of “730 0# ǂa Ali Baba (Folk tale)” as one of the examples of headings in conventional form and not normally provided with parallel non-Latin data. I also added a few examples in the 2.5.1 section (a 130 videorecording example; and a 240 non-translation example for the Persian work)

Google docs comments: I incorporated most (96.5%?) of your comments/examples into the text, or a compromise if more than one commented on the same thing, so if you wish and you have time, please check to see if you are satisfied that I incorporated them correctly (you will have to do a comparison with the document at the Google site (it would have been too unwieldy, and probably unintelligible, if I attempted to do track changes with this attachment)

Descriptive fields section 2.3 slightly reorganized: I numbered the sub-section of 2.3. Descriptive fields, 2.3.1, for mixed script fields, which includes also the guidelines on characters outside MARC-8, which itself is numbered (this illustrates that these fields fall within the parent rules).

Headings section renumbered: I renumbered the 2.5 heading section along Robert’s recommendations/revisions.

MARC tag order: each logical section of examples all are in MARC tag order where practical.

Terminology: the terms non-Latin, romanization (romanized, etc.) are used throughout. There may be some instances where speaking of “transliteration” were appropriate.

Fonts/spacing: I have made the document consistent with fonts, spacing, etc.

the word “Example(s)” is in italics with a colon introducing an example or examples sections

numbered section headings are in bold (except for sub-sections in 3. Special language or script guidelines)

some special paragraphs have an underlined introductory phrase (such as “Macros and automatic transliteration)

Examples, typically showing a paired field combination, are single line spaced, with bracketed explanations (in normal font) mostly directly beneath the example without an extra line space.

NACO variants: I added a recommendation in 2.5 (1st paragraph) to add variants to Name authority records as part of NACO.

Cataloger-Created: I changed the phrase “cataloger-supplied” to “cataloger-created” to distinguish cataloger-created parts of notes and qualifiers from the personal name qualifiers that are not cataloger created, but rather added based on usage of the name, and the term “supplied” could also apply.

Linking entries: I changed the instruction for linking entries (removed reference to the 580 note, since the principles are the same as in 2.4.: “ Linking entries (optional) (76X-78X), Give parallel non-Latin script linking entry fields when the entry for the linked record has been systematically romanized. I do not know why the CEG requires that the linked record also have non-Latin data (or that you would have to go to that record to add it). I also think we should NOT worry about providing an optional approach for these fields in 2.5.2. (these linking fields may be based on a descriptive 245 or they may be based on a 130 U.T., or 110/245, etc., whatever the main entry is for the particular serial)

Translations: On the issue with translations that came up when discussing the optional heading practice section, 2.5., I think I need to apologize for creating a false problem (I must have been overworked or something). If some libraries are creating parallel U.T. (or any heading for that matter) in the language of the piece in hand, which is not the original language of the person, work, or body, then it is simply incorrect practice. I added/amended the phrasing in both and “The headings [qualifiers] must be in the language/script of the body, person, or title, and the form entered can be derived from the resource itself or if necessary from a standard reference source in the language/script of the heading.”

Unpaired fields: I added in parentheses in Record characteristics, right after discussion of MARC Model A: “(There are a few exceptions where an unpaired non-Latin field is an appropriate option, depending upon the language/script)”, just to mention this early in the document, since later on there is one or two recommended options of adding unpaired fields, such as 246 (a Hebrew special language rule comes to mind); this is in addition to the added text in 2. General guidelines that Robert/Keiko suggested and some of you agreed to: “Other optional fields may be entered in Latin only, in non-Latin only, or in parallel Latin and non-Latin fields.” I think this all firmly establishes that required fields and headings are paired whenever providing the non-Latin data for them, but outside of these, pairing is optional.

BIBCO standard record: I added the text to the first intro section, 2nd paragraph: “The guidelines may be applied regardless of MARC formats, however the BIBCO standard record for print monographs has been applied to some examples.”

Hebrew contents note example from Sharon I incorporated into the general notes section 2.4.

Please send me your final comments ASAP either in an email or in the document via email attachment using track changes on that attachment and just inform me in the email where/what in the document your changes/comments are (e.g., which corrected examples).

I would like to submit this by next Thursday (Mar. 25) at the latest. Sorry about the short notice, but you all have been submitting excellent improvements for a while at this point, it is in a nearly finished state (as far as anything ever is) so we need to wrap it up, and, we are a little late submitting it. And, remember, this is meant to be a regularly amended document, so if PCC accepts the document and agrees to an amendment process, then revision proposals can be submitted via the approved venue (I am hoping coordinated by Standing Committee on Standards (who will perhaps farm it out to PCC and LC experts for advise, etc., when necessary)).

Many thanks,



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


Log In

Log In

Get Password

Get Password

Search Archives

Search Archives

Subscribe or Unsubscribe

Subscribe or Unsubscribe


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



CataList Email List Search Powered by the LISTSERV Email List Manager