It does not differ, it is the same semantic content. Surely, RDA and
MARC need to be compatible. Just as both need to be compatible with
ISBD, if the ISBD elements are still important. And just as both need
to be compatible with FRBR, if the FRBR model is important. (I
realize there is some disagreement in all of this).
But RDA needs to be expressed in language other than MARC. Why?
* Because we increasingly need to deal with data that comes from
outside the library world (and thus, not in MARC)
* Because we increasingly send data to outside the library world, and
into systems that are not MARC systems.
* Because the 'library world' is no longer in fact a discrete place
with clear boundaries. Catalogers and metadata librarians are
increasingly _cataloging and creating metadata_ in non-MARC formats.
This is happening already.
* Because MARC ought to be a data formatting/transmission format, and
our rules or guidelines ought to, of course, be compatible with it--
but ought not to tie us to to it.
* Because right now MARC ends up containing both a specification of
data elements (beyond ISBD), and instructions for their values
(beyond AACR2)---this creates a situation where it is very difficult
to change our practices and standards even in logical ways (because
it is unclear _where_ these practices and standards comes from), and
where it is very difficult to explain what we are doing both to new
entries to the field, and to those 'outside the library world' who
need to both use _and give us_ data. Formatting should be the realm
of MARC, rules or guidelines for data creation should be the realm of
RDA, and the enumeration and relationships of the data elements
themselves should be the realm of ISBD and/or FRBR. MARC must be de-
coupled from RDA---to be sure they must be compatible, but the only
way to start putting MARC in it's place as a formatting/transmission
format is to have RDA not actually use the language of MARC in
talking about elements. I would argue that both should use the
language of ISBD and/or FRBR exclusively. If ISBD and/or FRBR is
insufficient, then this must be noted (and will be noticed when we
commit to this type of care in our language), and changed.
[ I am aware that there is dispute over whether FRBR is needed at
all, with a position which on this list is principally articulated by
Mac saying, ISBD is perfectly sufficient as an enumeration of our
conceptual data model. If this is true, then RDA should _still_ not
be written in the language of MARC, but in the language of ISBD
exclusively. I submit that it is not true, and thus FRBR. In either
case, it is through carefully writing RDA in terms of a proper
standard for conceptual data model that insufficiencies in that
conceptual data model will be discovered and noted--and hopefully
fixed. An important thing to do for the reasons I tried to outline
above-].
Of course, even AACR2 was not written in the language of MARC, was
it? I think it would be a step backwards for RDA to be.
Jonathan
Of course, AACR2 was not expressed in language of MARC either, was it?
On Jul 1, 2007, at 2:30 AM, J. McRee Elrod wrote:
Johnathan Rockind said:
This seems like a perfectly reasonable and good solution to me,
On Jun 29, 2007, at 4:11 PM, Adam L. Schiff wrote:
I think from our discussion on this matter is that RDA needs
another >> element to record what I will call the "linking word or
term" in the title.
How does this differ from the MARC solution of:
245$aTitle$i.or,$bAlternate title?
As others have pointed out, this will require a change in ISBD to make
both the linking word and althernate title another element. But it
seems a far better solution to me than "coding", which may or may not
translate to what was on the title page for display.
Keeping our several standards in tandem is a major problem. I find it
easiest to begin with MARC, in part because MARC field tags make a
handy shorthand as opposed to the obtuse language of RDA.
Karen Coyle said:
Some people seem to be wanting to *describe* by >*transcribing*,
others are concerned about *access*.
In the days of card catalogues, the title main entry, or indented
title below main entry, served successfully as both description and
access. With MARC (from the mid to late sixties), 245$a has served
successfully as both description and access. Why mess with success by
complicating matters? (The 245$a title element has been far more
successful in this dual role the the 440 series element.)
Data is 245$b has been less successfully indexed because of the lack
of a filing indicator for initial articles, and other connecting
words. The creation of a 245$i subfield would solve that problem
nicely. (Some solve it in formatted 505 by $g$t.)
Sometimes the simplist solution is the best solution.
__ __ J. McRee (Mac) Elrod ([EMAIL PROTECTED])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__________________________________________________________
