[DCRM-L] BYU's 1st RDA/DCRMB record

[Noble, Richard]

Very preliminary thoughts below. My knowledge of RDA is very limited--this
has not been the summer for me to spend hours poring over it, though I know
it's coming like Hell *and* high water--but what the heck. - Richard

RICHARD NOBLE : RARE BOOKS CATALOGER : JOHN HAY LIBRARY : BROWN UNIVERSITY
PROVIDENCE, RI 02912 : 401-863-1187/FAX 863-3384 : RICHARD_NOBLE at BROWN.EDU


On Tue, Aug 10, 2010 at 8:01 PM, Robert Maxwell <robert_maxwell at byu.edu>wrote:

>  What  should we do about expansion of abbreviations, contractions,
> ligatures, etc.? RDA philosophy is “copy exactly what you see,” but as we
> know that is a bit simplistic for early title pages. Some possibilities I
> see:
>
> 1.       Continue to expand abbreviations, etc., exactly as we do now in
> DCRM(B), including the bracketing conventions (this is what I did in this
> record)
>
> 2.       Expand abbreviations, etc., without bracketing.
>
In 245, the transcription field, absolutely not. Limited representation is
one thing, false representation quite another.

> 3.       Do not expand abbreviations—but what about ligatures, symbols,
> etc.?
>
"Copy exactly what you see" is much closer to our transcription philosophy
than AACR2 and even DCRM(B).  Of course it's nonsense, since you're not in
any sense "copying" what you see: presumably you're still adding punctuation
*ad lib* as a substitute for grammatically significant line endings--and
certainly not indicating line endings as such or as in quasi-facsimile
transcription; not following original initial capitalization, let alone all
caps; etc. etc. It's simply a matter of *representing* what you see,
generally, but not always, with equivalent symbols, according to a set of
conventions. If you think of it as a species of encoding, then there are
degrees of thin and thick to be considered, and the possibility of options
along that scale.

The question that arises with respect to expansions is, basically: are you
representing characters or words? For actual abbreviations, i.e. words
shortened by omission of letters, exact transcription in the 245 seems to me
in the right "rare book" spirit. Likewise, the use of fairly basic
supplementary marks (tildes, macrons, etc.) might well be followed,
reckoning that Unicode and XML are the way of the future, and that anything
for which a codepoint is defined is to be regarded as standard (alternate
representations that accommodate system limitations to be either strictly
local, or to be provided in master records according to some one standard
for simplification. This also leaves open questions about defining character
standards, especially as regards equivalence/compatibility of combining and
precomposed characters.) The characters that Erin Blake referred to in her
response as "brevigraphs" (I really like that word), which presumably
include all those squiggles that we find in Cappelli, are more daunting.
Then there's i/j and u/v ...

At the most basic level, I'd be happy to see a more exact transcription in
the 245, with a range of suggested alternatives for 246s, to clarify and
inform, as well as for indexing. But it's not that simple. Do we continue to
rely on something like the transcription conventions found in the late
LCRIs? How do we avoid ambiguities in matching new records against old--i.e.
filling the database with "distinctions without a difference"? Do we suggest
that images ought to be the primary means of *identifying* (i.e. providing a
basic matching point), which has been the function of the 245?


>
> This issue is an issue that has to do with rare materials, and therefore
> would warrant under our principles a different approach from RDA if we feel
> it appropriate.
>
>
>
> Other RDA changes that do not have anything to do with rare materials (and
> therefore we would follow the general rules rather than have a special rule
> in DCRM) that you will note on this record:
>
>
>
> 1.       In RDA we don’t draw attention to errors; so in the AACR2 version
> the first bit is transcribed “Liber de potestatae [sic] syderu[m]” because
> it’s ungrammatical; in RDA there’s no “sic”: “Liber de potestatae syderu[m]”
>
As the ranks of well-informed catalogers get thinner and thinner it may be
best to let this go. That "[sic]" means you have to know that it's
ungrammatical--as for that matter do the expansions. Clearly this is one of
the aspects of RDA that appeals to the adminisphere: you need to know the
alphabet, but not a heck of a lot else... Anyway, having interpolated a
"sic" you need to provide a form of the title for the book to file on
properly. I wish there were a field for "primary filing version of the title
proper", leaving aside everything having more to do graphic representation.

> 2.       Physical description (300 field) is treated differently.
>
The example here is way too simple. What do we do with "[2], iv, [1],
iv-xvii, [3], 348 [i.e. 332], [6], 24, [2] p."? Interpolate five repetitions
of "unnumbered pages" into that sequence, and you begin to bury the
information that you're trying to convey--and that's simple, compared to
some things we encounter. This is where I sense that RDA may be wedded to a
foolish consistency: "NO brackets! NO abbreviations!" Are they nuts? Are we
supposed to abandon every convention of bibliographical description that
anyone actually interested in bibliographical description would know
perfectly well? Aren't they the people we do this for?

> 3.       Addition of content, media, and carrier types
>
Noting wrong with explicit metadata. Inference is death.

> 4.       In RDA abbreviation is almost forbidden, so in the signatures
> note I used “[paragraph mark]” in the RDA record instead of “[par.]”. I
> don’t think there’s any unique rare reason why we should use an abbreviation
> here. Related to this, though it doesn’t have bearing on this particular
> book: in RDA the format symbols are the same as in DCRM, except “folio” is
> spelled out, not abbreviated, e.g. … 32 cm (folio), not … 32 cm (fol.)
> Again, no rare reason why we need to abbreviate this word.
>
There is a for abbreviating: legibility and clarity. Read it aloud to
yourself, and imagine that the description actually calls for several such
lengthy phrases. Is this a point where we declare that we are no longer
limited to the typewriter's capacity for presenting symbols?

As to the formats, I should think that "folio", "quarto", "octavo" do it for
spelled out forms. After that it's perfectly correct to write "12mo",
"16mo", "18mo", etc., since that's what we usually say. (We can sacrifice
"duodecimo", since "twelve-mo" is frequently heard, and shorter. It's just
that we don't say "two-mo", "four-mo", etc., even though we could...)

> 5.       Note the form of the name in 100. The AACR2 form has “cent.”; the
> RDA form has “century”
>
6.       Note the form of the name in 700. The AACR2 form has “fl.”; the RDA
> form has “active”.
>
Bravo. "Florebat" or "floruit" are not needed, and "active" directly
translates the phrase used in many other languages.

> 7.       The use of relator terms won’t be unusual to us, except perhaps
> using one in 1XX fields. Also none of them are abbreviated in RDA (“editor,”
> not “ed.”)
>
I welcome this with open arms. I wish relators were in universal use and
properly indexed; but the main weakness had been their exclusion from 100
fields, and especially the use of nothing to represent something ("author").

>
>
> I’ve added RDA elements to the authority records for the two persons
> involved, but unfortunately I can’t produce them in any way that anyone else
> can look at them until October 1, when we can begin RDA work in NACO. For
> the moment they’re stored in BYU’s online save file.
>
>
>
> Comments are welcome; and especially discussion on DCRM-L on the issue of
> what to do with abbreviations, ligatures, symbols, etc., in transcribed
> areas under RDA.
>

I suspect that what's needed for this purpose is a survey of systems people.
What can current systems handle, and what do the prospects look like for the
immediate and farther future? What limits are imposed by OCLC?


>
>

>
> Thanks,
>
> Bob
>
>
Thanks, Bob, indeed!

- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20100825/a93b226e/attachment.htm