Re: Agenda for R&S Cataloging Meeting

[Yossi Galron]

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?