FYI - At the R&S Cataloging Panel on Tuesday 6/21 3:45-5:15 I will be
presenting a paper:
"Anticipating the use of Hebrew Script in the LC/NACO Name Authority File
The MARC 21 Format for Authority Data permits non-Roman scripts to be used
in authority records. LC/NACO Name Authority File (NAF) records are
currently restricted to Latin script because not all NAF distribution
recipients (who hold synchronized copies of the NAF master file) offer
support for non-Roman scripts. Headings in the NAF are established according
to AACR2 and LCRIs so headings from Hebrew script sources must be romanized.
This paper looks ahead to when we can use Hebrew and other scripts in
authority records. The options for using Hebrew script in MARC 21 authority
records are examined. The prospects for cooperative authority work between
American libraries and libraries in Israel are considered."
Some of the issues that Daniel and others are bringing on Heb-NACO will be
examined during the presentation. I hope that we will have time for
discussion after the presenations at that session.
I will add the issue of Hebrew dates in the parallel 260 field to the agenda
for the R&S Cataloging Committee.
Heidi
----- Original Message -----
From: "Caroline R. Miller" <[EMAIL PROTECTED]>
To: <heb-naco@lists.acs.ohio-state.edu>
Sent: Monday, June 06, 2005 9:08 AM
Subject: Re: Agenda for R&S Cataloging Meeting
> When I attended ALA in Orlando last year I was at the Authority Control in
> the Online Environment Interest Group (ACIG) meeting and heard Barbara
> Tillett speak on LC's ultimate plan to add non-roman scripts to the
> authority file when they came up on the Unicode version of Voyager. I
> believe she was referring to adding non-roman scripts in 4xx fields in
> authority records but I could be wrong. I had also heard Ann Della Porta
> of LC say the same thing at ALA Midwinter in San Diego in 2004. Maybe
> Barbara Tillett is now too busy with RDA (i.e. Resource Description and
> Access-- new name for AACR3) to be dealing with this issue right now.
>
> UCLA has been up on the Unicode version of Voyager since July 2004. We
> have been loading CJK and Arabic records in from OCLC and I am not aware
of
> any formatting problems. OCLC is implementing Hebrew, Cyrillic, and Greek
> in September of 2005. Daniel, I'll let you know more if I see any
problems
> once we start loading Hebrew script records from OCLC.
>
> --On Monday, June 06, 2005 11:00 AM -0400 Joan C Biella <[EMAIL PROTECTED]>
> wrote:
>
> > 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?
> >
>
>
>
> Caroline R. Miller
> Head, Monographic Cataloging and
> Authority/Database Maintenance Sections
> UCLA Library Cataloging & Metadata Center
> Charles E. Young Research Library
>
> [EMAIL PROTECTED]
>
