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?
