CJK-1. Recording Chinese character numerals in
Answer CJK-1 :
PSD, Feb. 27, 2012:
Date of production/publication and numbering within series/subseries are all elements that would be covered by 1.8 “Numbers Expressed as Numerals or as Words” and the sub rules of that instruction, when applicable (1.8.2-1.8.5). A string such as “二〇一二” represents numbers; so 1.8.2 is used. The instruction says to record the numerals in the form preferred by the agency, and the first Alternative is to record the numerals in the form they were found on the resource. LC currently applies the first alternative:
Non-Latin script field: 260 $a [Chinese characters] : $b [Chinese characters], $c 二〇一二
Latin script field: 260 $a [Pinyin equivalent of Chinese characters] : $b [Pinyin Romanization of Chinese characters], $c er ling yi ling (i.e., the Pinyin equivalent of the Chinese numerals) [note: PSD instead means "er ling yi er"?]
The Romanization of the numerals would depend on the Romanization scheme used, not RDA; while there is a section in the Chinese Romanization guidelines for non-Gregorian type dates, there is no special instruction for the Romanization of the Chinese numerals.
A cataloging agency could decide to apply the second alternative at 1.8.2 to also supply an equivalent numeral in a form preferred by the agency (in brackets) to the found numerals; LC has not yet chosen to apply this alternative, but our Chinese cataloging experts are interested in applying this alternative, such that the above example would read:
Non-Latin script field: 260 $a [Chinese characters] : $b [Chinese characters], $c 二〇一二 [2012]
Latin script field: 260 $a [Pinyin equivalent of Chinese characters] : $b [Pinyin Romanization of Chinese characters], $c er ling yi ling [2012] [note: PSD instead means "er ling yi er"?]
(note addition of date in Arabic numerals to the pinyin romanization)
**LC would be interested in the opinions of the Chinese cataloging community on the issue of possibly following the second alternative at 1.8.2 to supply an Arabic date in brackets**
260 $c 民國一百年[2011]
260 $c Minguo yi bai nian [2011]
We would agree that the date should be transcribed as found on the resource; we would also add, per 2.8.6.3 Optional Addition, the Gregorian date, in brackets.
PSD, Mar. 27, 2012: Our LC Japanese cataloging colleagues passed along the following response: "We have not been using spelled-out dates like "nisen-ju(macron)ni" in publishing dates." ... LC has been using arabic numbers for the ... 260 $c (date of publication, distribution, etc.) subfield ... For the 260 date of publication, even if the item has "二千十二年発行", we describe it in the 260 $c as 2012.
PSD, Mar. 28, 2012: LC has a decision in the Library of Congress Policy Statement (LCPS) to apply the alternative (i.e., record in the form on the resource).
ASME, Mar. 2, 2013: We think there needs to be a Policy Statement for 1.8.2 to say that the agency decision for numbers expressed with CJK characters should be recorded as Western-style Arabic numerals (similar to AACR2 C.5, but limited to the elements identified in 1.8.1). ... We are quite interested in CEAL's reaction to this proposed change, but note that any final decision would still need considerable discussion with other interested parties ... Possible wording for policy at 1.8.2 (main instruction, not alternative):
LC practice: For resources in Chinese, Japanese, and Korean script, substitute Western-style Arabic numerals for characters that represent numbers in the elements listed at RDA 1.8.1.
Because the elements in RDA Chapter 3 are not transcribed, the instructions in 1.8.2 relevant to numerals do not apply. If the “language of cataloging” is English, the extent would be recorded as “123 pages.” If a cataloging agency felt it was important to indicate to the user that the page numbers themselves were numbered with Chinese characters, a note on extent could be given (RDA 3.22.2) such as “Pages numbered with Chinese characters, final page numbered “一百二十三页”.
CJK-2. Romanization of Chinese characters numerals in edition statement such as Di yi ban or Di 1 ban for 第一版
Answer CJK-2:
PSD, Feb. 27, 2012: Edition statement is also not covered by 1.8.2; RDA 2.5.1.4 says to transcribe in the form found on the resource. 第一版 would be transcribed in the non-Latin field, and the Pinyin Romanization would be “Di yi ban”; likewise, 第1版 would be transcribed in the non-Latin field, and the Pinyin Romanization would be “Di 1 ban”.
ASME, Mar. 2, 2013: We've updated the examples below to reflect the suggestion above. Our Japanese cataloger indicates that while either reading is correct, we would be more likely to use “Dairokuhan.“
|
|
Example 1 |
Example 2 |
Example 3 |
Example 4 |
|
Source: |
第1版 |
第一版 |
제 일판 |
第六版 |
|
Record (Non-Latin): |
第1版 |
第一版 |
제 일판 |
第六版 |
|
Record (Translteration): |
Di 1 ban Di 1 ban |
Di 1 ban Di yi ban |
Che 1-p’an Che ilp’an |
Dairokuhan or Dairoppan Dairokuhan |
CJK-3. Undifferentiated name authority records
See "PCC Post RDA Test Guidelines", under "Personal name headings":
If an existing AACR2 authority record for a personal name is an undifferentiated name record and there is now a date of birth, a date of death, a fuller form of name, or a field of activity or occupation for the person related to the resource being cataloged, create an RDA differentiated name authority record for that person, remove the appropriate 670 fields from the AACR2 undifferentiated record, and report the necessary bibliographic file maintenance. For other situations, use the AACR2 undifferentiated authorized access point in the RDA bibliographic record. Do not add any 7XX fields for RDA forms to the undifferentiated AACR2 authority record.
( http://www.loc.gov/catdir/pcc/PCC-Post-RDA-Test.html )
CJK-4. Recording of Chinese-character series numbering "上卷". Back in AACR2, C.3B1, e):
Substitute Arabic numerals for numbers expressed as words
would have applied; and AACR2 series numbering in this situation would have been:
1-kan
in an Arabic numeral. Then, what about RDA numbering for this case? RDA,1.8.3 simply instructs us:
Substitute numerals for numbers expressed as words.
It does not specify which numerals (Chinese, Roman, Arabic, or otherwise), unlike AACR2 that spelled out "Arabic numerals". Should we substitute, when doing RDA cataloging, a Chinese numeral for a Chinese number expressed as a word in series numbering? I.e.,
上卷 --> 一卷?
Or, we still use Arabic numerals for recording RDA series numbering, when the resource presents it in Chinese characters?
Asnwer CJK-4:
PSD, Feb. 27, 2012:
RDA made an attempt to “internationalize” whenever possible. This resulted in the removal of many instructions that had an English-language bias, so that different cataloging agencies around the world could use RDA as written, with the understandings spelled out in RDA 0.11.3 giving the cataloging agencies the latitude to express a preferred numbering form and/or script. In the context of RDA 1.8.3, LC has not yet designated a preferred script for a numeral that would substitute for a word. Our suggestion would be as you suggest (上卷 --> 一卷), for now, but we can see that this may not result in a desired outcome in series numbering fields that are being sorted by series numbering. We also note that this type of numbering is very close to the concept of an ordinal number, although the Chinese character indicating an ordinal number is not present. **LC would be interested in the opinions of the Chinese cataloging community on this issue, specifically as to whether an Arabic numeral should be substituted for the upper, middle, or lower character. This is a decision that would need to be coordinated with other non-Latin script areas as well.**
ASME, Mar. 2, 2013:
|
|
Option 1 |
Option 2 |
Option 3 |
|
Source: |
上巻 |
上卷 |
上券 |
|
Record (Non-Latin): |
上巻 [1-kan] 上巻 |
上卷 上卷 |
上券 上卷 |
|
Record (Translteration): |
Jōkan [1-kan]
Jōkan |
Shang juan Shang juan |
1-kwŏn Sanggwŏn |
Note that this answer reflects what would be recorded in the 490 $v—the series statement-- as recorded from the item itself. We recognize that the series numbering in an authorized access point may be different, as indicated by the numbering field recorded in a series authority record. Since LC no longer supplies series access points or makes series authority records, we would leave this question to the PCC.
CJK-5. Recording of Chinese-character series numbering "第六卷". Back in AACR2, C.3B1, e):
Substitute Arabic numerals for numbers expressed as words
would have applied; and AACR2 series numbering in this situation would have been:
第 6卷
in an Arabic numeral. Then, what about RDA numbering for this case? Is Chinese character "六" a number expressed as a numeral or as a word? If a numeral, than RDA, 1.8.2 would apply:
第六卷
If a word, on the other hand, RDA, 1.8.3 would instead apply:
第 6卷
Answer CJK-5:
PSD, Feb. 27, 2012: We think the Chinese character “六” is being used as a numeral in this example.
PSD, Mar. 12, 2012:
Chinese character “六” is a numeral itself. RDA 1.8.5 “When recording ordinal numerals (expressed either as numerals or as words) taken from a source in Chinese, Japanese, or Korean, record them as numerals accompanied by the character indicating that the numeral is ordinal.” This paragraph is followed by Example:
第8
8th in Chinese
According to this instruction, we have to record it as第六卷 (Romanization: Di liu juan) rather than第 6卷. The current example in 1.8.5 shows an Arabic numeral as replacement, but we don’t know from this example what is actually on the resource itself (whether it’s第8 or第八 or 第捌 (character)).
Our Chinese experts think that we are compelled to define what exact numerals used to substitute CJK numerals, for example, use Arabic numerals to replace CJK numerals when recording ordinal numbers. We would value your advice.
I believe this applies to Japanese and Korean as well.
Followup question:
Is this applied to 490 field only or both 490/830 fields? If it’s also applied to 830 field subfield v, will it cause a confusing series numbering sorting in index display?
It may; this presents an inevitable conflict between the RDA principles of “representation” (how does something appear on the resource itself) vs. how systems may use the data. If the CJK community could reach consensus on an approach, we would be interested in hearing from you.
Our LC Japanese cataloging colleagues passed along the following response: "We have not been using spelled-out dates like "nisen-ju(macron)ni" in publishing dates." For RDA MARC records, does it have order for 500 notes like AACR2 MARC records?
CJK-6. A discussion on the PCCLIST regarding “examples of upgraded NARs with $c” in September 2012 indicated that LC Chinese catalogers had determined that $c das hi was NOT a religious rank or title, and as a result it was removed from the authorized access point for an important Buddhist master “Xingyun da shi” and replaced by his year of birth (1927-). In February 2012 a group of CJK catalogers submitted recommendations to the PCC Acceptable Headings Implementation Task Group to retain these three terms as is under RDA because in the majority of cases these terms were used as religious titles/names. The summary of the findings by CEAL members is: “Da shi (大师) can exist as either a religious title or general respectful address. The treatment should be determined case by case following authoritative reference sources. “Fa shi (法师)” is more likely to be a religious title but the same instruction can be given. “Shi (释)” is an acquired Buddhist name equivalent to “last name.” Note: these terms have equivalents in Japanese and Korean. They may be pronounced differently but should be treated the same way. We hope PSD will consider issuing a statement to instruct catalogers to carefully evaluate each heading when updating records containing these terms.
Answer CJK-6: ASME, Mar. 2, 2013: We agree with your conclusion about use of “Shi (释)” as part of the name itself, not a title or term of honour. We understand the difficulty of determining when “da shi” and “fa shi” are actually titles or a term of honour (which often requires research). We note that a new type of the RDA element “title of the person” will be added to RDA as a result of a proposal to change RDA from the British Library—it will add a category as 9.4.1.9 for “other term of rank, honour, or office” (see http://www.rda-jsc.org/docs/6JSC-BL-3-rev-Sec-final.pdf)-- this will allow for the recording of such terms *to break a conflict (only)* for those cases that it may be a term of honour rather than a religious rank. We hope such flexibility will be helpful in breaking conflicts, and eliminating some of the need for research. As noted above, it is not always easy to determine when “da shi” and “fa shi” are used as a title or a term of honour—we would propose an “in case of doubt” guideline that says to treat the term as a term of honour instead of a religious title if you don’t have evidence to the contrary; as a term of honour, it would only be added to break a conflict. Note that we would also propose that existing authority records that use “da shi” and “fa shi” should be treated as “acceptable” under RDA.
CJK-7. May a language note be given to specify whether a resource is in simplified or traditional Chinese characters?
Answer CJK-7: COIN, Mar. 26, 2013: Use a 500 note instead of 546 language note. Simplified and traditional Chinese characters belong to the same language and script.
CJK-8. The March 2013 revision of the provision at CSM, G 150 specifies additional languages in the language table, the Japanese language being among those additional ones. It carries:
CSM, G 150, Translation Table (Mar. 2013)
...
.x154 Hebrew translation
.x156 Japanese translation
.x16 Italian translation
.x164 Korean translation
...
with "Japanese translation" placed between "Hebrew translation" and "Italian translation" (rather than between "Italian translation" and "Korean translation") to result in alphabetical sequence disruption both in listing in the Table and Cutter-numbering in the shelflist. Although alphabetically out of sequence, should we nonetheless assign ".x156" to Japanese translations?
Answer CJK-8:
No, the languages should file alphabetically ... The corrected Translation Table is:
.x154 Hebrew translation
.x16 Italian translation
.x163 Japanese translation
.x164 Korean translation
CJK-9. LC still entered in April 2013 at least one new AACR2 (as opposed to RDA) authority record for an East Asian name.
008 130405n| acannaabn |b aaa
005 20130405130531.0
010 n 2013018680
040 DLC |b eng |c DLC
100 1 Wei, Shuguang, |d 1969-
N.B.: NAR dated Apr. 5, 2013; 008/10: c; no 040-|e
Has a notification from LC in this regard been received?
Answer CJK-9: COIN, Apr. 8, 2013: This and other non-CJK AACR2 records should not [be] created. We will make a note and correct them.
CJK-10: Non-Gregorian, on-Julian Dates for Serials/Integrating Resources/Multipart Monographs
There used to be the provision at Descriptive Cataloging of East Asian Material, 1.4F8:
Descriptive Cataloging of East Asian Material, 1.4F8
260 __ , $c Shōwa 11-12 [1936-1937]
260 __ , $c 昭和 11-12 [1936-1937]
NOTE: In providing multiple dates that are in different non-Gregorian, non-Julian sequences, it is CJK practice to give each date and its equivalent in the Julian calendar in separate brackets.
260 __ , $c Kwangmu 9 [1905]-Yunghŭi 3 [1909]
260 __ , $c 光武 9 [1905]- 隆熙 3 [1909]
not:
260 __ , $c Kwangmu 9-Yunghŭi 3 [1905-1909]
Is this convention still applied to RDA bibliographic records? In the last part of the resource, the publication date appears as "昭和 12" and not simply "12". Thus, would this rather be:
264 _1 , $c Shōwa 11 [1936]-Shōwa 12 [1937]
264 _1 , $c 昭和 11 [1936]-昭和 12 [1937]
?
Question 1. Manifestation-Level and Item-Level Microfilm Reproductions (Not Compilations)
I have reviewed RDA, LCPS, and LC training material on RDA cataloging of microfilm reproductions (not compilations), but I am not clear about the
distinction between manifestation-level reproduction and item-level reproduction, for the purpose of making field 776 references.
RDA, J obviously carries both: Reproduction of (manifestation); and Reproduction of (item). In LC's training module F (rev., Oct. 2011) at URL:
http://www.loc.gov/aba/rda/source/refresher_module_F_oct2011.ppt
Slide 43 shows an example of microfilm reproduction with:
776 0# [sic; "#" should instead read "8"?] ‡i Reproduction of (manifestation): ‡a ...
with a speaker note:
The relationship designator includes the parenthetical term "(manifestation)" because it is possible to have reproductions of items as well.
How should we make a distinction between the manifestation-level and item-level microfilm reproduction (not compilations) for RDA cataloging?
Answer 1.
PSD, Feb. 24, 2012: If you are going to make a distinction, RDA Appendix J.5.2 gives you the relationship designator “reproduction of (item)”. Whether you make the relationship to a manifestation or item is really a cataloger judgment question—we think catalogers would generally make the relationship to the item level in those cases where the purpose of the reproduction was to specifically bring out details in a particular item (copy) of a resource. For example, if a publisher were reproducing Thomas Jefferson’s copy of a book, specifically to bring out the margin notes that Jefferson wrote.
Question 2. Authority Field 370-‡c
Regarding authority field 370-‡c, while "MARC Authority to RDA Mapping" inside RDA maps it to RDA, 9.10 and that "MARC 21 encoding to accommodate RDA elements: LC practice for November 2011+":
http://www.loc.gov/aba/rda/source/marc21_changes_29sep2011.doc
appears to be in line with RDA allowance, LC/PCC document "MARC 21 encoding to accommodate new RDA elements 046 and 3XX in NARs and SARs":
http://www.loc.gov/catdir/pcc/RDA%20in%20NARs-SARs_PCC.pdf
appears to be more restrictive in use of authority field 370-‡c not mapped to RDA, chapter 9, but only to 10.5 and 11.3.2-11.3.3. Does Columbia follow latter's more restricted use provision of authority field 370-‡c?
Answer 2.
Question 3. Authority Field 370-‡a
For recording a place of birth under authority field 370-‡a, in case of jurisdictional name change between the time of an author's birth and cataloging, which place name do we record, the name as of the time of the author's birth or that as of the time of cataloging?
Answer 3.
PSD, Feb. 24, 2012: For sequential name changes (i.e., multiple authority records exist), use the authorized form for the time of the person’s birth.
OCLC, June 5, 2013: It seems like it would be better to just use the latest name of the place.
Question 4. RDA, 2.20.13.4
RDA, 2.20.13.4 simply instructs us:
Make a note identifying the latest iteration of an integrating resource consulted in preparing the description.
There are two examples, both with:
Identification of the resource based on: ...
RDA, 2.20.13.4 is for integrating resources. The situation is parallel in RDA, 2.20.13.3 for multipart monographs/serials with general instruction with examples:
Identification of the resource based on: ...
About RDA, 2.20.13.3 (as opposed to RDA, 2.20.13.4), ALCTS webinar on RDA and serial catalogers presented by Steve Shadle on Mar. 2, 2011 instructed us on slide 47 with a speaker note:
"Identification of the resource based on" is just wording in RDA examples. Still okay to say "Description based on:"
Does this interpretation of RDA, 2.20.13.3 for serials also apply to the provision at RDA, 2.20.13.4 for integrating resources?
Answer 4.
PSD, Feb. 24, 2012: Yes, these examples are not prescriptive, just illustrative. The JSC is in the process of forming a group to review all of the examples used in RDA—CEAL may want to contact CC:DA about examples you would like to see (CC:DA will nominate members of the JSC group for ALA).
Question 5. How should we code the authority 046 field/subfield when the birth or death year is not precise? E.g.,
AACR2: ‡d d. 945 or 6
RDA: ‡d -945 or 6
Answer 5. The "Extended Date/Time Format", as allowed in MARC 21 Authorities, may be used. E.g.,
046 __ ‡g [0945,0946] ‡2 edtf
Cf. "MARC 21 encoding to accommodate new RDA elements 046 and 3XX in NARs and SARs," p. 7 (July 15, 2011); "MARC 21 encoding to accommodate RDA elements : LC practice for November 2011+," p. 7 (Sept. 29, 2011).
Review Point 6.
"Frequently Asked Questions, Program for Cooperative Cataloging and RDA"
4.5 Can RDA elements, such as 046, 37X or 38X fields, be added now to existing AACR2 authority records?
Yes.
RDA elements, such as the 046 and 3XX fields, are defined in the MARC 21 Authority Format and may be added to AACR2 authority records. At the present time, there is no PCC policy on adding these fields to AACR2 authority records. As PCC ‘best practice’ decisions are adopted by the PCC and changes to the MARC 21 Format for Authority Data are implemented, PCC policy on the addition of these fields in AACR2 authority records will be documented. A chart describing the fields is on the PCC website.
(http://www.loc.gov/catdir/pcc/PCC-RDA-FAQ.html)
e.g.,
001 oca00652893
008 811215nc acannaabn ∎b aaa
005 20110218063848.0
010 n 81107835
046 ǂf 1914 ǂg 2008
053 0PL2822.S48
1001 Wang, Shumin, ǂd 1914-2008
370 Sichuan Sheng, China
375 male
377 chi
Question 7. All examples in RDA, 2.20.13.5 for the date of viewing of online resources have months abbreviated, such as the 2nd example: "Viewed on Jan. 13, 2000." Shall we input a spelled-out or abbreviated form for months in 500 viewed-on note?
Answer 7. The example appearing in RDA 2.20.13.5 is acceptable if the cataloger were following some other in-house guideline or style manual. Otherwise, the name of the month should not be abbreviated.
Appendix B deals with abbreviations. There are no instructions there that provide for abbreviating months in any element (and the only date-related abbreviations listed there are A.D. and B.C.) However, there is an alternative at B.1 which does allow for some flexibility: "When recording the attributes of a manifestation or item (see chapters 1–4 rdalink), if the agency creating the data has established in-house guidelines on the use of abbreviations, or has designated a published style manual, etc., as its preferred guide, use those guidelines or that style manual in place of the instructions given in this appendix."
LCPS B.1 (which eventually gets you to LCPS 1.7.1 provides more specific guidance on access points, linking entries, punctuation, uncertain dates and symbols, but nothing on abbreviations in notes. In addition, RDA 1.10 provides general guidelines on notes and although capitalization and quotation are mentioned there (along with other topics), there's no mention of abbreviating months in notes. That same alternative for the use of in-house guidelines is provided at 1.10.
Question 8. Single Other Title Information
Is there a provision in RDA/LCPS for recording single other title information parallel to AACR2/LCRI, 1.1E5? Or, should we simply follow the recording order given in RDA, D.1.1? E.g.,
in resource: Title proper in English; other title information in English; Parallel title proper in Chinese; no parallel other title information in Chinese
AACR2/LCRI: 245 00 Title proper in English : ǂb other title information in English = 中文書名.
In an RDA record, would the order of elements under field 245 for the same situation remain the same or would it rather be:
???? RDA: 245 00 Title proper in English = ǂb 中文書名 : other title information in English. ???
Answer 8.
PSD, Feb. 24, 2012: Since this is really a question about ISBD display, we would defer to ISBD to answer the question. The ISBD Consolidated edition (http://www.ifla.org/files/cataloguing/isbd/isbd_wwr_20100510_clean.pdf ) says this: 1.3.4.7.2 When a prescribed source of information bears one or more parallel titles, but the statement of other title information is in only one language and script, the other title information, if given, is given after the last parallel title transcribed.
Question 9: NACO Normalization
Is "NACO Normalization" revised for or does it no longer apply to RDA authority records? LC prepared and distributed the following RDA NAR with exactly the same string under authority field 100 and one 400:
010 n 2012000616
040 DLC ǂb eng ǂc DLC ǂe rda
100 1 Li, Weizu, ǂd 1918-
400 1 Li, Weizu, ǂd 1918-
670 Si da men, 2011: ǂb t.p. (李慰祖 = Li Weizu [in rom.]) ...
When systematic romanization of Chinese-character name matches publisher-provided romanization on t.p., should it now be repeated under field 100 and field 400, as long as coded RDA? Evidently, as long as coded AACR2, it is a conflict and not entered as such. This RDA NAR prepared and distributed by LC fails validation on Connexion Client.
Answer 9:
PSD, Feb. 24, 2012: NACO normalization applies the same in RDA as it did in AACR2 (i.e., it applies to NACO, regardless of content standard). The record as represented above was a simple mistake and was corrected and re-distributed on Feb. 1, 2012.
Question 10: Recording of Colour and Sound Content
RDA, D.1.1 specifies the order of elements to be recorded. According to it, for other physical details, colour content is to be recorded before sound content, which agrees with Adam Shiff's presentation of May 7, 2011 (slide 71, speaker note) at URL:
http://faculty.washington.edu/aschiff/BCLAPresentation.ppt
300 1 videodisc (116 min.) : ǂb colour, sound ; ǂc 12 cm
However, most, if not all, RDA bibliographic records for DVDs instead carry sound content first and then colour content. E.g.,
300 ... 1 videodisc (75 min.) : ǂb sound, color ; ǂc 4 3/4 in.
(LCCN 2010614374, etc.)
Also, Karen Griggs/Pam Grace's presentation at URL:
http://rdaandcjkworkshop.pbworks.com/w/file/49940694/BYU_AV_RDA.ppt
carries their instruction on slide 20:
300 1 videodisc (121 min.) : ǂb sound, color ; ǂc 4 3/4 in.
What is the correct order of recording the colour and sound content in RDA bibliographic records for videodiscs:
color, sound
OR
sound, color
?
Answer 10:
PSD, Feb. 24, 2012: I believe these are merely examples, and the order does not matter.
Question 11: Punctuation in Bibliographic Linking Entries
LCPS, 1.7 refers cataloguers to CEG, 76X-78X, section 1 on punctuation in bibliographic linking entries, which instructs cataloguers:
1. Input a period following subfield ǂa, ǂs and ǂt (when followed by ǂb).
2. Do not input a period at the end of any other subfield.
However, LCPS, 1.7 carries an example:
775 08 ǂiReproduction of (manifestation):ǂaVerdi, Giuseppe, 1813-1901.ǂtOtello.ǂdMilan : Ricordi, ©1913
with a full-stop following ǂt although not followed by ǂb, despite the CEG provision, to which LCPS, 1.7 directs cataloguers. How should we understand this? What is the correct punctuation in bibliographic linking entries?
Answer 11:
PSD, Feb. 24, 2012: We took this example straight from MARC 21, without testing it against the CEG provisions—we’ll get it corrected (the same example appears in the LCPS for Appendix J.1). MARC itself is very unclear about punctuation in linking entry subfields, which is why we referred to the CEG guidelines rather than “reinventing the wheel.”
Question 12: Ending Punctuation in Bibliographic Field 245, when the Last Word is an Abbreviation with a Full-Stop
RDA, D.1.2.1 obviously instructs cataloguers:
When an element ends with an abbreviation followed by a full stop or ends with the mark of omission and the punctuation following that element either is or begins with a full stop, include the full stop that constitutes or begins the prescribed punctuation.
It is clearly understood that, when the last word is an abbreviation with a full-stop under bibliographic field 250, there should be two full-stops at the end of bibliographic field 250. Likewise, when the last word is an abbreviation with a full-stop under bibliographic field 300 and when that bibliographic field 300 is followed by bibliographic field 490, there should be two full-stops at the end of bibliographic field 300. Then, how about bibliographic field 245? MARC 21 bibliographic carries this proviso:
Field 245 ends with a period, even when another mark of punctuation is present, unless the last word in the field is an abbreviation, initial/letter, or data that ends with final punctuation.
This exception clause of "unless the last word in the fiedl is an abbreviation" is absent in MARC 21 bibliographic for bibliographic fields 250 and 300.
Answer 12:
PSD, Feb. 15, 2012: Some of the instructions in MARC 21 have not fully caught up to some of the recent changes in ISBD display that are found in RDA's Appendix D. The ISBD Review Group (a section within IFLA) is also reviewing Appendix D right now, in consultation with the JSC; it is not clear at this point whether they will also make suggested changes to Appendix D or to MARC 21.
Given the flux of the current situation, LC has given instructions in the LCPS for 1.7.1-- relevant to 245 and 250 it says:
Fields 245, 250. If either field 245 or 250 does not end in a period, add one.
We think for now this is the simplest instruction, and may re-evaluate if ISBD and/or MARC 21 revise practices.
Question 13: AACR2, C.2B3, Sentence 2
Should we assume that the provision at AACR2, C.2B3, sentence 2:
Use lowercase roman numerals in paging or page references even when capitals appear in the item.
does not have any equivalent in RDA? e.g., Would
extent based on AACR2: iv, 553 p.
be:
extent based on RDA: IV, 553 pages
?
Question 14: B.C. with Span of pre-Christian Dates
How should we understand and apply:
RDA, H.1: Use the abbreviation B.C. for dates in the
pre-Christian era. Place the abbreviation
at the end of a date or span of dates in
that era.
***BUT***
RDA, 9.3.4.3: approximately 494 ***B.C.***-approximately
467 ***B.C.***
As quoted above, in the case of a span of B.C. dates, RDA, H.1 instructs us to place one "B.C." at the end of the span, while RDA, 9.3.4.3 shows to us a case of two "B.C.", not only at the end of the span but also immediately following the start date.
Answer 14:
PSD, Feb. 24, 2012: Our feeling is that the example at 9.3.4.3 should follow the instruction in Appendix H1. I should note, and this is where it gets a bit complicated, that a date span as mentioned in Appendix H1 only occurs for period of activity. In RDA, date of birth and date of death are separate elements-- MARC's deficiency means that there is not an ability for coding them separately (thus the technique of connecting them with a hypen), but a hyphen in that situation doesn't reflect a span in the H1 context, just a connector between birth and death dates lacking any other mechanism.
PSD, Feb. 28, 2012: They are separate dates in RDA (Date of birth, Date of death), and I think they need to 'stand on their own' (e.g., if a user is looking for all the people born in 4XX B.C. and the B.C. isn't found in the Date of birth element, it won't work). By the time we pour them back into MARC 100 fields, both dates get concatanated into $d, and a hyphen needs to be added to distinguish the birth date from the death date. Having combined and hyphenated a birth and death date in MARC does not seem to me to meet the "span of dates" instruction in H1-- you still have two separate dates that have only been given the appearance of a span by MARC. We think the Pericles example in in H1 is correct; we think the Brutus example in 30.1.1.3 is incorrect, because those are birth and death dates, not a period of activity span.
Because 9.3.4.3 is covering the "Period of activity of the person" it is itself a single attribute, and can be given with a single date or a range of dates. A range in this context is still a single attribute and seems to fall into the H1 instruction to place the abbreviation at the end of a date or a span of dates in that era in a way that a birth and death date wouldn't be treated.
Birth and death dates-- they are separate attributes. Activity dates, as a separate and single attribute that may have a date or a range of dates seems to be what the 'span of dates' in H1 is referring to. We'll try to write this up for the JSC in the context of changing the period of activity example in 9.3.4.3 to follow H1, and to fix the Brutus example in 30.1.1.3-- it may raise for them that they don't really want H1 to say what it says-- should be clarity either way.
Question 15: Session 2, Part 1, #1
When a person, family, or a corporate body involves multiple relationships with a resource, how would such a situation be coded in a MARC 21 bibliographic record? Would one access point field for the person, family, or corporate body receive multiple subfield e's or would multiple fields (as opposed to subfields inside one field) be entered?
Answer 15
HM, Mar, 17, 2012: See:
RDA, 18.5.1.3
Record one or more appropriate terms from the list in appendix I with an identifier and/or authorized access point representing the person, family, or corporate body to indicate the nature of the relationship more specifically than is indicated by the defined scope of the relationship element itself.
Note: ... one or more appropriate ***terms*** [emphasis added] ... with ***an*** [emphasis added] ... authorized access point representing the person, family, or corporate body ...
Therefore, for coding in a MARC 21 bibliographic record, when a person, family, or a corporate body involving multiple relationship designators, one access point field for the person, family, or corporate body receives multiple subfield e's.
Question 16: Session 2, Part 3, #1
When one of the multiple creators of an original is no longer responsible for a revision but other creators still are, would the revision be considered a new work or new expression?
Answer 16
HM, Mar. 17, 2012: See:
RDA, 6.27.1.5
... If more than one person, family, or corporate body is responsible for the adaptation or revision, construct the authorized access point representing the work applying the instructions on collaborative works given under 6.27.1.3.
If the work is presented simply as an edition of the previously existing work, treat it as an expression of that work (i.e., use the authorized access point representing the previously existing work).
Therefore, when one of the multiple creators of an original is no longer responsible for a revision but other creators still are, if the revision is presented simply as an edition of the original, the revision is treated as a new expression, but if the revision is not presented simply as an edition of the original, the provision at RDA, 6.27.1.3 is applied.
Question 17: Session 4, Part 2, #1
In LC RDA bibliographic record:
010 __ |a 2011568265
020 __ |a 9780193378049
040 __ |a DLC |b eng |c DLC |e rda
700 1_ |a Nakayama, Shinpei, |d 1887-1952. |t Sunayama.
700 1_ |a Kitahara, Hakushu(macron), |e lyricist.
700 1_ |a Takano, Tatsuyuki, |d 1876-1947, |e lyricist.
700 1_ |a Bennett, Charles, |d 1954- |e writer of added lyrics.
700 1_ |a Chilcott, Bob, |e arranger of music.
700 12 |a Nakayama, Shinpei, |d 1887-1952. |t Sunayama; |o arranged.
700 12 |a Okano, Teiichi, |e composer. |t Vocal music. |k Selections.
the authorized access points starting with "Nakayama, Shinpei, |d 1887-1952" did not receive any relationship designator, while access points for other persons did. Why was it the case?
Answer 17
HM, Mar. 17, 2012: See RDA, 0.6.6, where the *relationship designator* for a person, family, or a corporate body associated with a resource is *not* made a core element.
With regard to optional addition of a relationship designator to a name-title authorized access point, see:
http://lib.stanford.edu/metadata-department/stanford-rda-questions-and-answers#13
Therefore, in LC RDA bibliographic record LCCN 2011568265:
700 1_ |a Nakayama, Shinpei, |d 1887-1952. |t Sunayama.
could ***optionally*** read instead:
700 1_ |a Nakayama, Shinpei, |d 1887-1952, |e composer. |t Sunayama.
Question 18: Session 2, Part 1, #2
Is there an order of 5XX notes in RDA MARC records, as in AACR2 MARC records?
Answer 18
HM, Mar. 13, 2012: RDA, D.1.1 presents ISBD order of RDA elements; and RDA, D.2.1 presents mapping of MARC 21 bibliographic data to corresponding RDA elements, such as field 5XX notes, field 300ǂb, etc. However, RDA, Appendix D is being reviewed. [Cf. Answer 12 above.]
Question 19: Session 2, Part 1, #3
What does LCPS stand for?
Answer 19
HM, Mar. 13, 2012: LCPS stands for Library of Congress policy statements. Similar to LCRI having complemented AACR2, LCPS complement RDA.
Question 20: Session 2, Part 1, #4
Difference between compilation and collaboration?
Answer 20
HM, Mar. 13, 2012: Compilation is aggregate work through selection and putting together works, or parts of works by one or more creators (Cf. RDA, I.3.1). Collaboration is through multiple creators working together on the entire work (Cf. "RDA Special Topics: Compilations & Collaborations," Dec. 2011, slide 15 (http://www.loc.gov/aba/rda/source/special_topics_compilations.ppt))
Question 21: Session 2, Part 1, #5
What is a main entry for a compilation? What about collaboration?
Answer 21
HM, Mar. 13, 2012: The main entry is not in RDA terminology. An authorized access point of compilation is constructed with the initial element for the title (RDA, 6.27.1.4). An authorized access point of collaboration is constructed with the initial element for the principally-responsible creator (RDA, 6.27.1.3).
Question 22: Session 2, Part 1, #6
If taking the Alternative provision at RDA, 6.27.1.3 to include in the authorized access point representing the work the authorized access points for all creators, how would those creators be entered in MARC 21 bibliographic records? Under bibliographic field 1XX or 7XX?
Answer 22
HM, Mar. 13, 2012: Current MARC 21 bibliographic field 1XX is not repeatable and cannot accommodate multiple creators. Also, LCPS instructs cataloguers not to apply this Alternative provision at RDA, 6.27.1.3.
Question 23: Session 2, Part 1, #7
In a situation covered by RDA, 6.27.1.4 (compilation lacking collective title), which title is recorded?
Answer 23
HM, Mar. 13, 2012:
RDA, 2.3.2.9
When preparing a comprehensive description for a resource that lacks a collective title, record the titles proper of the parts as they appear on the source of information for the resource as a whole.
under MARC 21 bibliographic field 245.
RDA, 6.27.1.4
If the compilation lacks a collective title, construct separate access points for each of the works in the compilation.
under MARC 21 bibliographic fields 700/710/711/730.
Question 24: Session 2, Part 3, #2
Is an authorized access point a main or added entry?
Answer 24
HM, Mar. 13, 2012: Neither the main entry nor the added entry is in RDA terminology. An authorized access point is a standardized access point representing an entity (RDA, Glossary).
Question 25: Session 2, Part 3, #3
Shouldn't a statement of responsibility taken from a source other than the preferred source of information (for instance a writer of an art catalog mentioned in the preface but not on the title page) be square-bracketed?
Answer 25
HM, Mar. 13, 2012: In an RDA bibliographic record, a statement of responsibility, as long as taken from somewhere inside the resource, even when from outside the preferred source of information, is not square-bracketed. Cf. RDA/LCPS, 2.2.4.
Question 26: Session 2, Part 3, #4
In the case of art catalogs, for the same resource, when an AACR2 main entry and an RDA creator are different, is there an impact on LC classification number assignment?
Answer 26
HM, Mar. 13, 2012: Even when a text writer of an art catalog of a single artist, with reproduction of art works and text, is an RDA creator, the LC classification number is still for the artist and not for the text writer, as the subject matter of such a catalog is a separate issue from who is treated as a creator of the art catalog. When the artist number is the first Cutter, Table N6 is usually applied for the second Cutter, which is "A4" for an art catalog.
Question 27: Session 4, Panel Discussion, #1
What use would occupation, profession, or field of activity have for differentiating one personal name from another?
Answer 27
HM, Mar. 13, 2012: JSC recently decided to cancel the provision to use the field of activity for differentiating one personal name from another. This decision is expected to be reflected in an upcoming RDA update. [Further development since Mar. 13, 2012: JSC released on Mar. 16, 2012: http://www.rda-jsc.org/docs/6JSC-CILIP-3-rev-Sec_final-16mar.pdf]
Question 28: Session 4, Panel Discussion, #2
Are a title page verso and a colophon sources of information, as far as RDA is concerned? Can a title page verso be considered a colophon?
Answer 28
HM, Mar. 13, 2012: Any location inside the resource itself may be a source of information. As to the preferred source of information, please review the provision at RDA, 2.2.2. Both AACR2 and LCRI had a glossary entry for "colophon." However, neither RDA nor LCPS defines a "colophon", although CC:AAM Task Force on RDA did file a request of CC:DA for relaying to JSC the concern over absence of "colophon" in the draft RDA glossary.
Question 29: NAR Authority Field 670s
Should recording under NAR authority field 670s follow RDA provisions (e.g. title page) or DCM Z1 provisions (e.g. t.p.)?
Answer 29
LC, Apr. 20, 2012: ... referring everyone to DCM Z1 for guidance, so the 670 transcription will follow DCM Z1 .
Question 30: RDA, J.2.6 versus RDA, Element Set, Related Work
For recording, in RDA bibliographic records, "sequel to" relationship, it appears that RDA and RDA, Element Set instruct us differently.
RDA, J.2.6:
Sequel to
RDA, Element Set, Related Work:
Sequel to (Work)
May we omit " (Work)", when we record a "sequel to" relationship in RDA bibliographic records, despite the provision at RDA, Element Set, Related Work? If not, should "W" be in upper case as at RDA, Element Set, Related Work?
Answer 30:
PSD, May 7, 2012: We believe that RDA J.2.6 is the most up-to-date version of the relationshipp--since there is not a "Sequel to" relationship at an entity level other than "work" there is no need to qualify the relationship designator. If I'm not mistaken, I think a pre-publication draft may have included the sequel relationship at the expression level which was subsequently changed, but the element set view has not yet caught up-- some of the JSC constituencies are currently reviewing the Element Set to see that it conforms with RDA itself (same with some of the other mapping tools), but this may take some time.
Question 31: Hyphen or No Hyphen with Year and Month Under Authority Field 046
When entering a year and a month (but no date, due to unavailability), under authority field 046, I have been inserting a hyphen between the year and month:
e.g.,
046 __ |f 2012-05
although no hyphen is inserted when entering a year alone or a year, month, and date:
e.g.,
046 __ |f 2012
046 __ |f 20120510
as per:
However, I have just realized that MARC21 Authority and DCM, Z1 instruct us otherwise:
Which should we follow:
yyyy-mm (with hyphen)
OR
yyyymm (with no hyphen)
when entering a year and month (but not date) under authority field 046?
Answer 31:
PSD, May 18, 2012: We had recognized the discrepancy between what MARC told you to do (allegedly to follow ISO 8601), and ISO 8601 itself, and asked the Network Development and MARC Standards Office to change the MARC instruction accordingly, which they did just last month. It now shows the hyphen used with the year/month construction:
The date and time are recorded according to Representations of Dates and Times (ISO 8601) in the pattern yyyy, yyyy-mm, or yyyymmdd (4 for the year, 2 for the month, and 2 for the day) unless subfield $2 (Source of date) specifies another date scheme.
... a revised DCM Z1 page for the 046 with the corrected syntax, and even added an example to illustrate-- unfortunately, that revision won't be published until August (because of the quarterly Cataloger's Desktop cycle):
046 ## $f 1946-06
100 0# $a Vickers, Roy Henry, $d 1946-
670 ## $a Solstice, c1988: $b t.p. (Roy Henry Vickers) jkt. (native Indian artist; b. June, 1946, Greenville, British Columbia)
Question 32: Parallel Title Proper only on Dust Jacket
For RDA cataloguing, is a dust jacket of a print resource that consists of pages considered to be within the resource? A parallel title proper of a print resource that consists of pages only appears on a dust jacket and nowhere else. To such a case, does RDA, 2.3.3.2 apply?
Answer 32:
PSD, June 12, 2012: Our interpretation has been that the jacket is not considered part of the resource. CC:DA has a group looking at the "sources" instructions in RDA for possible revision-- they may be coming up with wording to clarify this.
Question 33: Authorized Access Point in RDA BIBCO Bibl. Corresponding to AACR1 NAR
When an authorized access point in an RDA BIBCO bibliographic record being prepared corresponds to an AACR1 (008/10: b) NAR, what should we do with that NAR? May we or may we not convert it into an RDA NAR? If we may not, then, should we not make the RDA bibliographic record for BIBCO? The NAR in question is:
LCCN: n 78021121
008/10: b
Answer 33:
PSD, June 12, 2012: Any pre-AACR2 heading may be changed to either AACR2 or RDA at any time.
Question 34: Reproduction of Serial
We have for RDA cataloging a reproduction of a serial. The reproduction publisher is different from the original publisher; and the original serial already ceased publication. Although the reprint publisher states that they tried hard, they could only locate 10 percent of the issues supposed to have originally been published; and only those 10 percent of the issues from the original serial are what is reprinted.
Even to this situation, is the provision at RDA, 2.13.1.3, Table 2.1:
serial: ... Includes ... reproductions of serials.
applied?
Answer 34:
PSD, July 3, 2012: ... the North American community worked hard to get the "reproductions of serials" included in the definition in RDA, so that gives you the ability to catalog the reproduction as a serial. The LCPS for 0.0 does acknowledge that some republications of serials can still be treated as monographs (e.g., when only a single issue is republished, or an "anniversary" issue/volume of selected issues that otherwise give the impression of being a monograph-- in other words, the republisher has consciously selected a small number). In your case, it seems that the publisher's intent was to reproduce the whole serial, even if they couldn't really do so, so I think you could treat as a serial if you choose.
Question 35: Punctuation for Manufacture Statement under Bibliographic Field 264
When preparing RDA bibliographic records in MARC 21 format, should a manufacture statement entered under bibliographic field 264 (with 2nd indicator "3") be enclosed in parentheses as instructed at RDA, D.1.2.5?
MARC 21 bibliographic carries an example with no parentheses:
264 #3 $aCambridge : $bKinsey Printing Company
There is no specific provision in that respect in "PCC Guidelines for the 264 field" (June 11, 2012).
Answer 35:
PSD, July 13, 2012: No, the manufacture statement should not be in parentheses when using the MARC 264 field under RDA. Appendix D represents ISBD practice, but has not been updated to reflect recent changes-- the ISBD Review Group (a branch of the International Federation of Library Associations) has been asked to review the Appendix, and the JSC is seeking volunteers to revise the MARC mappings in the Toolkit.
We'll consult with the MARC Standards office to see if a note can be added to the format.
Question 36: MARC 21 Authority Field 008/29
The PoCo statement entitled Decisions Table from Task Group to Formulate/Recommend PCC/NACO Policy on Authority Issues (High Priority) Report (rev., Sept. 11, 2012) carries:
008/29: 11 Sept. 12: Continue to code 008/29 "a" or "n" for now.
It does not mention anything about "b" under MARC 21 authority field 008, byte 29. Is "b" no longer entered under 008/29 in NARs or SARs with non-Latin script references? Almost all CJK NARs and SARs are affected.
Answer 36:
PSD, Sept. 17, 2012: No, no change yet, at least we're still using the value 'b' with 667 fields for non-Latin scripts.
Question 37: Authority Field 5XX-ǂi
RDA in NACO Training, Module 2.b, slide 7, example 2 carries:
500 1 Crosby, David, ǂd 1944- ǂw r ǂi Group member:
May "ǂi Group member:" be placed as the initial element preceding ǂa instead?
Answer 37:
COIN, Sept. 28, 2012: Absolutely—the OCLC display will be:
500 1 ǂi Group member: ǂa Crosby, David, ǂd 1944- ǂw r
Question 38: Discontinued x-refs. through Places in NARs for Local Churches
When recoding a record for a local church from AACR2 to RDA, should we also remove the 410 through place? This practice was discontinued in 1995. LCRI, 24.10B, Place Qualifiers, Note 2 said to remove such references when editing the record for another reason, but neither RDA nor LCPS, 11.13.1.3 carries the instruction to delete such a reference.
Answer 38:
COIN, Sept. 28, 2012: Yes, please do that.
Question 39: Approximate Date under Authority Field 373
How do we enter an approximate date pertaining to an associated group under authority field 373? MARC 21 format for authority data specifies that authority field 373-ǂ2 is for a code that identifies the source of a controlled vocabulary for affiliation terms in ǂa (rather than ǂs or ǂt), unlike authority field 046-ǂ2. One case that we have is:
010 __ n 82099383
100 1_ Matsumoto, Ikuyo
670 __ ... around 1927 at Hirafuku Hyakusui art sch.; …
We do not have any further information on this author than what appears under pre-existing field 670.
373 __ Hirafuku Hyakusui Art School ǂs 1927~ ǂ2 edtf
would not be correct, as per the provision in MARC 21 format for authority data. Also, this does not validate through Connexion Client, due to "edtf" under ǂ2.
Answer 39:
COIN, Sept. 28, 2012: There is no way to input an edtf date in a 3XX field because you cannot specify source of date scheme in them. ǂ2 is defined differently for those fields. In the 373 field, it's defined as source of term, so putting ǂ2 edtf in the 373 means edtf is the source of term for the associated group, which makes no sense. I would just leave the date off of the 37X fields when it is not certain and let the 670 take care of it, or perhaps even the 678, if you add one.
Question 40: Field 046 Coding of Conflicting Dates
Is there a best practice for dealing with conflicting dates for coding under authority field 046s? A case for re-coding from AACR2 to RDA (no change of 100) is:
coded AACR2
LCCN: n 50062066
100 1 Honda, Katsuichi, ǂd 1933-
various pre-existing 670s:
b. 11/1931 (registered b.d.)
b. 1/28/1932
b. 4/28/1933
The resource in front of us for RDA cataloging has: b. 1931. How should this be coded under authority field 046?
-multiple 046s OR single 046-ǂf?
- *if* single 046-ǂf, date corresponding to 100-ǂd alone OR range of possible dates OR set of possible dates, e.g.,
046 __ ǂf 1931-11/1933-04-28 ǂ2 edtf
046 __ ǂf [1931-11,1932-01-28,1933-04-28] ǂ2 edtf
Answer 40:
PSD, Feb. 27, 2013, via COIN, Feb. 28, 2013:
1) If your research results in more than one year of birth and/or death, you have these options for the 100 subfield $d:
a) Use your judgment to select the year(s) that either predominate -- appear in more resources, OR
b) Select the year(s) that appear in the most recent publications
c) And use those dates in the 100 subfield $d
d) If it is impossible to determine the most likely year(s) based on the above, do not add a subfield $d to the 1XX (hopefully, there will be no conflict, and if so, other distinguishing elements may be applied to the 1XX)
2) 046
a) All dates may be recorded in the 046 field(s), regardless of the year(s) that might appear in the 100 subfield $d
b) PSD recommends (and this is contrary to [COIN's response, Sept. 28, 2012]) that you use multiple 046 fields and add a subfield $v to the end of each on to show the source of that date.
c) ... it is possible to combine dates from those two schemes in one 046 field. However, the one exception, as noted in the BL Guide to RDA Name Authority Records, is the coding of YYYYMMDD in the 046. Under edtf, the formatting would include hyphens: YYYY-MM-DD and we are not applying edtf in that case, so the only circumstance that would allow you to record a mix of ISO 8601 date(s) and edtf dates is when you have years only, whether firm or questionable.
d) When in doubt use multiple 046 fields.
COIN, Sept. 28, 2012: I recommend using one 046 field. The 046 field is repeatable, and it would not be wrong to repeat it, but it just makes more sense to me to try to convey the dates in one 046. I prefer taking the most reliable birth year (1931 in this case, since it has 50% usage) and then make it questionable, either:
046 ǂf 1931~ ǂ2 edtf or
046 ǂf 1931-11~ ǂ2 edtf
This just makes the display easier for the reader. The two suggestions you have added above would be fine as well:
046 __ ǂf 1931-11/1933-04-28 ǂ2 edtf
046 __ ǂf [1931-11,1932-01-28,1933-04-28] ǂ2 edtf
Question 41: Arrangement Order of Elements in Personal Name AAPs
For personal name AAPs, when an available date still does not resolve a conflict and when a profession/occupation is added to differentiate personal names, what is the order of arranging elements? RDA, 9.19.1.1, para. 2 instructs us:
RDA, 9.19.1.1, para. 2
Make additions to the name as instructed under 9.19.1.2-9.19.1.6, in that order, as applicable.
Also, RDA in NACO Training, Module 2.b, Slide 5, bullet 2 instructs us:
RDA in NACO Training, Module 2.b, Slide 5, bullet 2
RDA 9.19.1.1 tells us to use the attributes in the order presented in 9.19.1.2-.7
- $c Title, $d Dates, $q Fuller Form, $d Period o fActivity, $c Profession or Occupation ...
Does the "order" in those passages pertain only to the sequence in application of those provisions without regard to linear arrangement of affected elements for construction of authorized access points? Or, does the "order" also specify linear arrangement of affected elements?
In one of the current LC RDA training documents, the following example is shown:
100 0_ ǂa Hellanicus ǂc (Grammarian), ǂd active approximately 200 B.C.
( http://www.loc.gov/aba/rda/pdf/name_authority_examples_oct2011.pdf (p. 4))
with the profession/occupation placed before the period of activity.
In addition, LC changed the following LC RDA NAR in elements arrangement:
LCCN: n 2011074213
cancelled RDA AAP: Hong, In-suk, ǂd 1973- ǂc (Artist)
replacement RDA AAP: Hong, In-suk ǂc (Artist), ǂd 1973-
As shown above, although both LC versions (cancelled AAP and replacement AAP) are coded RDA, LC reversed the elements arrangement from date-profession/occupation to profession/occupation-date.
Answer 41:
COIN, Oct. 6, 2012: Of the examples given,
Hong, In-suk, ǂd 1973- ǂc (Artist)
Yue, Ming, ǂd 1949- ǂc (Language teacher)
are correct ones. Date comes before profession.
COIN, mid-Nov. 2012: Right—the phrases “in that order” and “in the order presented…” mean that the attribute is selected from the lists in that order—it has nothing to do with MARC 21 subfield order (RDA is very good about telling you what to record, but intentionally does not take a stand on where to record it!)
Question 42: Placement Order of Subfields ǂv and ǂ2 under Authority Fields 372-374
Ana Cristán's "ALCTS RDA webinar. Recording RDA elements in MARC 21 fields in name authority records" (Sept. 12, 2012), on Slide 48:
373 ## $a National Retired Teachers Association $s 1947 $v Wikipedia, May 30, 2012 $u http://en.wikipedia.org/wiki/Ethel_Percy_Andrus $2 naf
373 ## $a AARP (Organization) $s 1958 $v Wikipedia, May 30, 2012 $u http://en.wikipedia.org/wiki/Ethel_Percy_Andrus $2 naf
Are these two examples prescriptive of the placement order of subfields ǂv and ǂ2, under authority fields 372-374? There is an example in DCM, Z1 to the contrary:
DCM, Z1, 046:
372 ## $a Industrial relations $2 lcsh $v Lazzarini, Sergio G. CV-English, viewed Feb. 22, 2012 $u http://www.sergiolazzarini.insper.edu.br/indexelazza.html
Answer 42:
COIN, Nov. 13, 2012: Subfield $2, if coded, should precede subfield $v or a combination of subfield $v + $u. Thanks for catching that slide from the ALCTS presentation. Aside from that, there is no guidance on placement. I always put the subfield $2 after the last element to which it applies, and before any subfield $s or $t:
372 $a Biotechnology $a Genetic engineering $2 lcsh $s 2008
not:
372 $a Biotechnology $a Genetic engineering $s 2008 $2 lcsh
Question 43: Placement Order of Subfield ǂ3 under Bibliographic Fields 336-338
There is a discrepancy between MARC21 and LC examples regarding the placement of ǂ3 in 336-338 elements in the bibliographic record. MARC21 shows examples of placing ǂ3 at the end of these elements, but the examples in the LC training show ǂ3 at the beginning. Which one is correct?
Answer 43:
PSD, mid-Nov. 2012: $3 in MARC has no absolute placement. General practice is to put it as the first subfield, as it is usually 'scoping' the data in the field, but you can find varying approaches in MARC because of this flexibility-- we went with first subfield because it usually is introductory, and we use it that way per MARC examples in 533, 856, etc.. I think in our own LC environment, the only exception to this is MBRS, which under AMIM always puts $3 last in the 300 field. Not 'wrong' either way.
Question 44: Re-Coding AACR2-Compatible/Pre-AACR2 Name-Title NARs to RDA
When a name-only NAR is recoded from AACR2-compatible or pre-AACR2 AAP to a different RDA AAP, we had better re-code associated name-title NARs so that the name portion will remain in synch. Then, in such a name-title NAR recoded to RDA, do we keep cancelled name-title AAP through the superseded form of the name?
A case for a Japanese translation that I have in front of me is:
recoded from AACR2-compatible to RDA
LCCN: n 50009222
new 100: McCabe, James D., ǂd 1842-1883
100 retagged 400: McCabe, James Dabney, ǂd 1842-1883 ǂw nne
Then, associated name-title NAR:
recoded from AACR2-compatible to RDA
LCCN: n 82242267
new 100: McCabe, James D., ǂd 1842-1883. ǂt New York by sunlight and gaslight
??? Should cancelled 100 be retagged as 400 ???:
McCabe, James Dabney, ǂd 1842-1883. ǂt New York by sunlight and gaslight ǂw nnea
Answer 44:
COIN, Dec. 5, 2012: It is fine to give such a variant, but wouldn't be required (you are really trying to show the variant for the name part, which was done on its own authority record); the systems that flip based on such 4XXs would be happy for it to be there, though.
As for coding the $w if you gave it, I think I would fall back on the "in case of doubt" rule for ǂw (nnea).
Question 45: Titles of Nobility
A Japanese translation of one of the works by the following author is being cataloged in accordance with RDA.
AACR2
LCCN: n 78095587
100 1 Disraeli, Benjamin, ǂc Earl of Beaconsfield, ǂd 1804-1881
667 THIS 1XX FIELD CANNOT BE USED UNDER RDA UNTIL THIS RECORD HAS BEEN REVIEWED AND/OR UPDATED
This case appears as an example in both AACR2 and RDA; and the indication in both AACR2 and RDA is the same:
AAP: Disraeli, Benjamin
VAP (later name): Beaconsfield, Benjamin Disraeli, Earl of
(AACR2, 26.2A1; and RDA, 9.2.3.8)
Now, while AACR2, 26.2A1 clearly shows the example with AAP of "Disraeli, Benjamin", its corresponding NAR coded AACR2 has it differently with "Earl of", which appears under VAP but not under AAP in the AACR2 (and RDA) example.
Is the pre-existing NAR coded AACR2 already incorrect even as an AACR2 NAR? If so, I will simply correct it and, at the same time, will recode it to RDA. However, if the pre-existing NAR coded AACR2 is correct as an AACR2 NAR, despite the example at AACR2, 26.2A1, then, for the same reason that I do not know, should an RDA AAP in NAF continue to be different from the example at RDA, 9.2.3.8, which is the same as the example at AACR2, 26.2A1?
Answer 45:
BL, which PSD further consulted, Dec. 12, 2012: Disraeli is best known as Benjamin Disraeli; there's no reason to include the title with the name in the authorised access point, and the variant access point is reasonably formulated in 9.2.3.8. I would be happy for the authorised access point to be changed to:
100 1 Disraeli, Benjamin, ǂd 1804-1881
Question 46: LCRI, A.4A1
I assume that the provision at LCRI, A.4A1:
LCRI, A.4A1:
When the title begins with an introductory word used in apposition to the noun or noun phrase that follows it, capitalize both the introductory word and the word following.
Série Ecrivains du XXe siècle
...
is no longer in RDA or LC-PCC PS.
Now, what should we do in our RDA BIBCO records, when a corresponding authority record for a preferred title is already established based on this LCRI capitalization instruction? The case that I have in front of me is:
coded AACR2
LCCN: nr2005028486
130 0 Shiri(macron)zu Fukushi ni ikiru
with "F" capitalized in the preferred title, because of the LCRI provision. "Fukushi" means welfare, is not a proper noun; and I capitalized "F" back in 2005 simply because it was (and still is) preceded by "Shiri(macron)zu" (Japanese word for "series").
Answer 46:
PSD, Jan. 2, 2013: do not change the capitalization in the existing SAR, but follow instead the general principle from DCM Z1 Introduction "In order to minimize the impact of database maintenance with associated bibliographic records and/or name/title authority records, catalogers are urged to refrain from making unnecessary changes to 1XXs."
Question 47: DCM, Z1, 046, subfield $v, para. 3
In DCM, Z1, 046, the following is instructed:
DCM, Z1, 046 (rev., Apr. 2013)
If the information in 046, 37X, 381 is in the same form as found in the source, there is no need to cite usage information. If the information recorded in 046, 37X, 381 is in a different form from that in the source, use 670 $b (Information found).
What is meant by "usage" for authority field 046? Then, in relation to authority fields 37X and 381 (as opposed to 1XX and 4XX), are we now required to be concerned about "usage"? Is/are there (a) typographical error(s) in the part quoted above? If so, how should we read this part?
Answer 47:
COIN, June 21, 2013: This statement in DCM Z1 046 section is the result of questions on whether or not to always cite locations when opting to justify attributes with subfield $v or subfield v + subfield u at the end of the field. ... the instruction applies more to non-date attributes, but there may be some cases where it applies to dates. Here is an example—if you see a statement like this in the foreword to a print resource: “so-and-so is 75 years old” you might want to deduce a possible birth year for the person to record in the 046 field. Since the actually birth year is not given in the resource, you would need to be sure to include the statement “so-and-so is 75 years old“ in the 670 area, in a subfield $b. You cannot use the subfield $v or subfield v + subfield u in this case. But here is a case where you could do it. If the resource has a statement like this: “so-and-so’s” career as a novelist began with the publication of XYZ in 2008), you could do something like this in the 046:
046 __ $s 2008 $v Name of resource, 2013
since the date was explicit in the resource.
Question 48: "v." versus "volume" in Bibliography Notes
When following the provision at LC-PCC PS, 7.16.1.3, Bibliography Note, para. 2, and when the book in question is a multi-part resource, is the provision at RDA, B.5.5 applied and "v." used for Latin alphabet term "volume"? E.g.,
505 __ Includes bibliographical references (v. 2, pages 226-228).
while "pages" is indeed spelt out, as per the table at B.7? Two different treatments in this regard are seen in LC and PCC records. E.g.,
LCCN: 2012519161
504 __ Includes bibliographical references (volume 2, pages 2161-2270).
LCCN: 2012503189
504 __ Includes bibliographical references (volume 5, pages 252-255) and indexes.
versus
LCCN: 2012465980
504 __ Includes bibliographical references (v. 1, pages 277-290) and index.
LCCN: 2012510440
504 __ Includes bibliographical references (v. 2, pages 883-927) and index.
Answer 48:
COIN, Apr. 15, 2013: The word volume should be used in the 504 field—spelled-out. I corrected 2012465980 and 2012510440.
Question 49: Machine-Converted RDA NAR not Actually in RDA
There is the following NAR that the machine converted from AACR2 to RDA, the AAP of which is not really based on RDA provisions.
coded RDA
LCCN: nr2001028215
100 1_ Takeda, Izumo, ǂd -1747
400 1_ Takeda, Izumo, ǂd d. 1747 ǂw nnea
As seen above, the machine changed "d. 1747" in the AACR2 version of AAP into " -1747". However, the machine did *not* know that it also needed ", ǂc I", between subfields "a" and "d", as per the new RDA provision at RDA, 9.2.2.9.5, para. 2. An RDA AAP should instead be:
100 1_ Takeda, Izumo, ǂc I, ǂd -1747
When the RDA-coded AAP is further reformulated with subfield "c" based on the RDA provision, what should be done to the current AAP that the machine generated, which is based on neither AACR2 nor RDA provisions, although coded RDA? Should it be retained under field 400? If so, is subfield "w" needed? If so, what code should be entered under subfield "w"? Again, the current form under field 100, while coded RDA, is based on neither AACR2 nor RDA.
Answer 49:
PSD, June 7, 2013: It is not necessary to codify the machine generated error in any way simply correct the heading ...
Question 50: Authority Field 372 Entry from LCSH--Reciprocity?
When an LCSH string calling for reciprocity, if used in bibliographic records under field 6XX's, is entered under *authority* field 372, is that reciprocity convention applied inside the *authority* record?
e.g.,
authority field 372 __ China--Foreign relations--Japan ǂa Japan–Foreign relations–China ǂ2 lcsh
OR
authority field 372 __ China--Foreign relations--Japan ǂ2 lcsh
?
Answer 50:
COIN, Aug. 5, 2013: It is not required ... SHM does not govern the coding of the 372 field, but you just need to be sure that if you code subfield ǂ2 lcsh, the heading or heading—subdivision combination is acceptable under LCSH (and not necessarily the SHM).
Question 51: Linear Jurisdictional Name Change
A linear jurisdictional name change case is encountered. The former name is represented by a NAR; and the current name needs to be established. DCM, Z1, 551 instructs cataloguers:
DCM, Z1, 551
Do not use subfield $i or subfield $w codes until relationship designators for places are developed. (Currently RDA has a placeholder for Appendix L).
Should "ǂw a" or "ǂw b" no longer be added for linking linear jurisdictional name changes? Or, is this provision as quoted above indication only of not entering "ǂw r"?
(The case has tentatively been processed with "ǂw a" and "ǂw b" (LCCNs n 87919102 and no2013071681), which will be revised, if necessary.)
Answer 51:
COIN, Aug. 5, 2013: In this case, continue to use subfield ǂw a/b to show the earlier/later. The intent of DCM Z1 551 section is to prohibit the use of relationship designators ...
Question 52: RDA AAPs Affected by RDA Rule Changes, July 2013
When readily known or when encountered, do we reformulate AAPs already done as RDA NARs but based on pre-July 2013 rules that went through changes with the July 2013 RDA update or do we leave such AAPs as they are if already done as RDA NARs?
One category relates to periods of activity of families: RDA, 10.10.1.3 --> RDA, 10.4.1.3:
pre-July 2013 RDA, 10.4.1.3: 4th-9th centuries
post-July 2013 RDA, 10.4.1.3: 4th century-9th century
Do we change or leave RDA AAPs for families with the pre-July 2013 RDA notation?
Answer 52:
COIN, Aug. 5, 2013: I would consider those pre-July RDA names to be “RDA-acceptable” under the updated guidelines, and not make any changes to them.
Question 53: Punctuation/Spacing for Authority Field 372 when Indicating Subfield
Does the convention of no spaces between the words and the double dashes under authority field 372, when indicating subfields, also apply to an open date followed by further subdivision? For instance:
LCCN: sh2008106024
150 __ Japanese literature ǂy 1868- ǂx History and criticism
Should this also be entered under authority field 372 with no space:
372 __ Japanese literature--1868---History and criticism ǂ2 lcsh
resulting in three hyphens "---"; or may we insert a space between the first hyphen and the dash:
372 __ Japanese literature--1868- --History and criticism ǂ2 lcsh
?
Answer 53:
COIN, Aug. 5, 2013: Please insert a space between the 1868- and --History and criticism. This is a type of LCSH shorthand that is used when double dashes replace delimiters, since delimiters will automatically close up extraneous spaces on either side. In the absence of a delimiter, there needs to be some type of shorthand that sets off the two subdivisions, and the space fulfills that need.
Question 54: Conflict between Pre-Existing VAP for Real Person and To-Be-Established Preferred Name for Fictitious Character
There have been some electronic mail exchange and BL's proposal discussed at the Nov. 2013 JSC Meeting with regard to construction of fictitious character AAPs.
The encountered situation is:
pre-existing NAR for real person:
coded AACR2
LCCN: n 90711744
100 1_ Takada, Kenzo
400 0_ Kenzo
to-be-established fictitious character not represented in LCSH:
preferred name: Kenzo(macron)
As seen above, VAP "Kenzo" in the pre-existing NAR for the real person and preferred name "Kenzo(macron)" to be established for the fictitious character would normalize the same. It is understood that, despite the provision at RDA, 9.19.1.2.f), qualifier " ǂc (Fictitious character)" is *not* routinely added to AAPs representing such cases, but only to break conflicts. In this situation:
(1) Should one update the VAP (the birth year is known of this fashion designer, 1939- ) to make it unique in the pre-existing NAR for the real person and establish a new AAP for the fictitious character without qualifier " ǂc (Fictitious character)"?
OR
(2) Should one leave the VAP in the pre-existing NAR for the real person and establish a new AAP for the fictitious character with qualifier " ǂc (Fictitious character)"?
Answer 54:
RDA experts, Dec. 16, 2013: It seems that in this case it would be best to add the qualifier Fictitious character to a new record. It seems to be more helpful for
the patrons; and one does have a conflict situation. We'll need to watch this discussion and see if the guidelines get changed.
Question 55: AAP for Imperial Prince (great grandson of a Japanese emperor)
An RDA NAR needs to be established for a great-grandson of a Japanese emperor. The resource for cataloging is a reproduction of (manifestation) LCCN 70821130 , in which the name is entered as:
010 __ ǂa 70821130
245 00 ǂa Tsunahito Shinno(macron) ...
600 00 ǂa Arisugawa no Miya Tsunahito, ǂc Prince of Japan, ǂd 1785-1845. [from old catalog]
( http://lccn.loc.gov/70821130 )
- There is no NAR, even coded pre-AACR2, in NAF.
- "Tsunahito" was his forename.
- "Shinno(macron)" means Imperial Prince.
- None of his parents or his grandparents was an empress/emperor, but his great-grandfather was.
RDA, 9.2.2.20, para. 2 does *not* apply to this case. So, following para. 1 in the same rule, going back to RDA, 9.2.2.18:
preferred name: Tsunahito
Or, would Imperial Prince be another characteristic mentioned in para. 3:
If a person is commonly associated with ... other characteristics (in resources associated with the person or in reference sources), include these words or phrases as an integral part of the name.
? If not, should we stop here for AAP formulation omitting "Shinno(macron)" for Imperial Prince, although still adding dates? Even if proceeding to RDA, 9.4.1.4, there may be no rule to apply at any rate, since he was a great-grandson of an emperor--neither with highest royal status nor consort of royal person nor child/grandchild of royal person. Or, would RDA, 9.4.1.9 "other term of rank/honour/office" apply?
Answer 55:
COIN, Dec. 19, 2013: This is a tricky one, ... it is also heavily dependent on cataloger’s judgment. ... would consider Imperial Prince to be an “other identifying characteristic” from RDA 9.2.2.18 and include that in the name ...
100 0 Tsunahito, ǂc Shinno(macron), ǂd [dates]
And as with all other “on-the-line” cataloger’s judgment issues, this one could be revisited in the future.
Question 56: Recording of Core Element, Title of Nobility, when Not Recorded under AAPs
NARs are established for Japanese barons. When each of them was alive (1841-1911 and 1876-1936), each was a baron, but the title of nobility does not appear with each name in resources associated with each or in reference sources. Thus, the title is not added under AAPs. However, the title of nobility is a core element as per RDA, 9.4 and needs to be recorded somewhere else than under AAPs. Then, under which MARC field should the title of nobility, baron (Jpn: danshaku), be recorded? Although, certainly, "RDA to MARC authority mapping" inside RDA toolkit maps RDA, 9.4 to MARC 21 authority field 368ǂd, DCM, Z1, 368 still instructs us:
DCM, Z1, 368
Until further notice LC/PCC catalogers are asked NOT to supply the following subfields: $d (Title of person), ...
Answer 56:
COIN, Apr. 28, 2014: Well, this is a Catch-22. You have the title but then PCC policy at this point does not allow you to use the correct MARC field to record it. So in order to satisfy the RDA instruction at RDA 9.4, you can record it in the 670 field and possibly in a 678 Biographical Data field. But until the 368 subfield $d is activated for NACO use, you can apply a go-around way to include this information, albeit not as precisely, in the 368 field—in subfield $c Other Designation. By including 368 $c Nobility $2 lcsh you are getting at the title, and if you explicitly record it in the 670 or 678 field(s), at one time, once the subfield $d in 368 is activated for NACO, a machine or a person might be able to then do what I wish you could do now—add 368 $d Baron or $d Danshaku.
Question 57: Subfield Coding of VAPs Entered with Hereditary Titles
What is the correct MARC subfield coding of a variant access point entered with the hereditary title (e.g., danshaku [Jpn for barons])? A NAR was tentatively entered:
LCCN: no2014047227
100 3_ Shijō (Family : ǂd 1894- )
400 3_ Shijō, ǂc Danshaku (Family : ǂd 1894- )
400 3_ Shijō, ǂc Barons (Family : ǂd 1894- )
Under field 100 "Family" is under ǂa, which is simple. Then, how about under field 400? According to MARC 21 format for authority data, ǂa is not repeatable under field 400; and OCLC Connexion client rejects insertion of "ǂa" between "Danshaku" [Jpn for barons]/"Barons" and "(Family". As such, should the type of family be entered under 400ǂc as tentatively shown above?
Answer 57:
COIN, Apr. 28, 2014: Although a family name is “name” in MARC, and family names are included in the instructions in MARC AF 100, implying that subfield $c is eligible for inclusion in a family name, ... recommendation would be to include Danshaku and Barons as part of the subfield $a, and do not separately subfield code the elements, i.e.:
400 3_ Shijō, Danshaku (Family : ǂd 1894- )
400 3_ Shijō, Barons (Family : ǂd 1894- )
Question 58: RDA, 11.2.2.21.1
The provision at RDA, 11.2.2.21.1 is basically the same as that at AACR2, 24.23A1. It is:
RDA, 11.2.2.21.1
Record the name of a civil or criminal court as a subdivision of the jurisdiction whose authority it exercises. Record the name in the form of a subdivision of the authorized access point representing the jurisdiction.
Omit the name (or abbreviation of the name) of the place in which the court sits or the area which it serves. If the name of the place or the area served is required to distinguish a court from others of the same name, add the conventional name of the place in parentheses.
Yet, confusion arises with examples immediately below the RDA provision:
France. Cour d'appel (Grenoble)
Name: Cour d'appel de Grenoble
France. Cour d'appel (Lyon)
Name: Cour d'appel de Lyon
India. High Court (Himachal Pradesh, India)
Name: High Court of Himachal Pradesh
India. High Court (Karnataka, India)
Name: High Court of Karnataka
Italy. Corte di appello (Rome)
Name: Corte di appello di Roma
Italy. Corte di appello (Trieste)
Name: Corte di appello di Trieste
Inside the parentheses, these examples show:
Grenoble ; *not* Grenoble, France
Lyon ; *not* Lyon, France
Rome ; *not* Rome, Italy
Trieste ; *not* Trieste, Italy
These are readily understandable. Then, why, on the other hand, inside the parentheses are shown:
Himachal Pradesh, India ; with ", India", rather than Himachal Pradesh
Karnataka, India ; with ", India", rather than Karnataka
? Is there a rule somewhere to handle place names in India in this context differently? Are such exceptions only with place names in India or those in Asia in general (such as China, etc.)?
Answer 58:
AALL catalogers, Nov. 13, 2014: These examples, at RDA, 11.2.2.21.1, for courts in India look wrong. A group of AALL [=American Association of Law Libraries] catalogers checked more Indic courts in NAF and realized that a large number of them are entered as in the RDA examples. We will proceed as a group to correct all those AACR2 NARs for Indic courts.