I agree with Yossi's comments, and this has been my practice in the Hebrew fields.
Ruth A. Rin Hebraica Cataloging Librarian University of Pennsylvania Quoting Yossi Galron <[EMAIL PROTECTED]>: | | | I am totally in agreement that in the Hebrew/Yiddish 260 | field we should transcribe the date in Hebraic letters and not convert | the date to numerals (i.e. tav-shin-samekh-he and not 765. If there is no | regular date we should continue add in brackets [2004 o 2005] | <<In Hebrew - alef-vav, and not "or" in | English>> | | See for example: | | | | http://library.ohio-state.edu:8081/search/o?SEARCH=19165459 | | | I would also have a list of Hebrew abbreviations we use in cataloging for | the Hebrew fields: not "ca." but | "be-erekh" in dates, Not d. | <died> but "met" or "nif." <niftar> | ; Not b. <born>, but no. <nolad>, etc. | | | I have also my opinion on a Hebrew Authority file ... but this we | will probably discuss in Oakland. | | | Yossi | | | | | At 12:16 PM 6/6/2005, you wrote: | | Daniel: In a similar vein, I wonder if we | should discuss the possibility of entering the real Hebrew date (i.e., in | Hebrew characters) in the parallel 260, since the Gregorian date and | transliterated (trans-numerated?) Hebrew date have already been captured | in the Romanized field, and since we provide a more faithful | transcription this way, and since it would cut down on the number of | bi-directional subfields. | | | | Joan: This idea is not likely to fly on a | national scale as long as AACR2 specifies roman expressions like | "c" (for copyright date) and "or" (for complex date) | in the 260$c. Though RLIN21 makes the Unicode Western-style | numerals available from the Hebrew character set, these other things | can't be provided without left-to-right input. Hebrew | "equivalents" for the problematic strings ("o" for | "or" and the like) make the departure from AACR2 | obvious. | | | | Steven: I have always been under the | impression that the scope of the AACR is limited to Roman script records | for use by English speakers. Vernacular non-roman script | records--since they cannot be used by the standard English speaker--are | not of any concern to the AACR. Our general approach to cataloging, | which combines Roman script fields (which follow the AACR standard) with | parallel vernacular fields (which do not follow the AACR standard) has | neccesitated that we apply AACR standards to parallel vernacular fields | so that our records have a feeling of consistancy. In applying the | AACR to non-English fields, we have the option to "replace the | [rules'] specified preference for English by a preference for [our] | working language" (AACR2 0.12). Entering the real Hebrew | date (i.e., in Hebrew characters) in the vernacular 260 would be allowed | because it is the preference for our working language. | | I am, of course, a relative rookie in this field and my impressions and | understandings on this matter could be completely off. | Thoughts? Comments? | | | | | ----- Original Message ----- | | From: "Joan C Biella" | <[EMAIL PROTECTED]> | | To: | < | heb-naco@lists.acs.ohio-state.edu> | | Sent: Monday, June 06, 2005 11:00 AM | | Subject: Re: Agenda for R&S Cataloging Meeting | | | Daniel. Do you think we might have time to talk about Unicode formatting | of bi-directional fields? Or perhaps this is too systems-specific | for a catalogers meeting? Jerry Anne raised the question today | about whether the parallel 100 field ought to have a [nun] rather than a | "b." in subfield $d, wondering about the long-term display and | data processing implications. I realize that the very idea of | Hebrew-script controlled vocabulary access points is problematic (in a | way that, say, the imprint data in the 260 isn't) since in this there's | no Hebrew-script controlled vocabulary to draw on. But it reminds me of | how often the question comes up about bidirectional script, Unicode | formatting characters (which I think I've got a handle on), and general | guidelines for producing national-level multi-script records. | | Joan. I think you're talking about the whole big idea of a | "controlled nonroman authority file," including controlled | vocabulary (and I assume "control" would include decisions on | what brand of dates, what kind of characters to write them in, | etc.). As you know, LC has (up to now) stated categorically that it | did not intend to sponsor a project to control nonroman headings. | However, there are definitely libraries out there that do*I've never paid | attention to which ones, but you can tell from the style of their | nonroman headings that they do. | | In the new day of "floating authority records," or whatever the | official term is for Barbara Tillett's concept, I'm not sure the | categorical refusal of the past will have any relevance*I mean, why | restrict IN ANY WAY the references people want to make? Why | SHOULDN'T they use non-Latin digits to record dates, and so on? | (Heidi, being the researcher on the subject, maybe knows why, but I | don't.) | | Setting this aside, though, there's no rule to forbid a library, or group | of libraries, from deciding to create a controlled nonroman authority | file for its own use. (LC might or might not be allowed to | participate*if not, it would be on the grounds that controlling yet | another file would take too much time and energy, which has always been | the rationale against it.) | | So AJL is free to do so, as far as I can see. LC-slash-AACR2 (who | knows about AACR3?) would have no way to prevent it, and wouldn't even | want to (I mean, we've never told the libraries that already do it, not | to do it.) Somebody*you?--would have to round up some libraries and | get them to agree to support the idea, and then (in some way) enforce the | decisions that are made about it. For sure LC will not do | that! | | If you are only talking about controlling the superstructure-type | vocabulary, such as how you express "b." and "d." and | "Selections" and so forth, it's a lot easier than if you also | want to control the actual headings. But either way I don't see a | way to say it's not possible or not allowed. | | | Daniel. In a similar vein, I wonder if we should discuss the possibility | of entering the real Hebrew date (i.e., in Hebrew characters) in the | parallel 260, since the Gregorian date and transliterated | (trans-numerated?) Hebrew date have already been captured in the | Romanized field, and since we provide a more faithful transcription this | way, and since it would cut down on the number of bi-directional | subfields. | | Joan. This idea is not likely to fly on a national scale as long as AACR2 | specifies roman expressions like "c" (for copyright date) and | "or" (for complex date) in the 260$c. Though RLIN21 makes | the Unicode Western-style numerals available from the Hebrew character | set, these other things can't be provided without left-to-right | input. Hebrew "equivalents" for the problematic strings | ("o" for "or" and the like) make the departure from | AACR2 obvious. | | | Daniel. Maybe people already using the Unicode version of Voyager could | tell us about the effects of various formatting techniques once records | are downloaded? | | Joan. About this, I know nothing, never having paid attention. LC | has a nonpublic Unicode version of its database, and I could look at some | copycat records in it and draw some conclusions, but I won't take the | time unless I'm asked to do it. Could you explain in more detail | what sorts of things you would look for? Are you thinking of how | dates of birth and death in headings/references display, for | example? | | | | | --
