Of course, RDA 1.8 doesn't _require_ an element to do double duty as
both transcription and access point, it merely permits it. There is
nothing to prevent a given implementation community from not applying
1.8 and creating separate elements in all cases.
-----Original Message-----
From: Resource Description and Access / Resource Description and Access
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Jones
Sent: Tuesday, May 06, 2008 12:46 PM
To: [email protected]
Subject: Re: [RDA-L] RDA Vocabularies Project
True: I had forgotten RDA 1.8.
-----Original Message-----
From: Resource Description and Access / Resource Description and Access
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Rochkind
Sent: Tuesday, May 06, 2008 11:56 AM
To: [email protected]
Subject: Re: [RDA-L] RDA Vocabularies Project
If RDA instructs the cataloger to create only one data element to serve
two purposes, then it's an RDA problem. If RDA instructs the cataloger
to create two data elements (or gives an option of two, with a legacy
option of one for legacy data), but MARC doesn't allow separate data
fields for those two elements--then it becomes a MARC problem.
Jonathan
Ed Jones wrote:
This is an artifact of the card catalog, where such double-duty
elements
made perfect sense. The elements involved are typically the title of
the resource being described and/or the title of the resource of which
it forms a component part (series, multivolume monograph, etc.).
Having
said that, I think this is more a problem of MARC 21's double-duty
datafields (specifically 245 and 440) than of RDA.
Ed Jones
National University (San Diego, Calif.)
-----Original Message-----
From: Resource Description and Access / Resource Description and
Access
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin M. Randall
Sent: Tuesday, May 06, 2008 10:26 AM
To: [email protected]
Subject: Re: [RDA-L] RDA Vocabularies Project
At 10:52 AM 5/6/2008, Karen Coyle wrote:
Would it be possible to separate the descriptive transcription of
fields
>from the linking and relationships between "resources" (considering a
book a resource AND the series itself as a resource). In the talk I
did
at Code4Lib I used the publisher name as an example. There would be
good
reasons to link bibliographic records to records for publishers (at
least for modern works). The latter could have contact information or
at
least link to the publisher information in ones acquisitions system.
This is NOT the same information as the transcribed publisher name
that
is in the publication statement.
That last sentence is spot on. It seems that we've gotten so afraid
of
redundancy that we think things that often *look* the same actually
*are*
the same. But to record the same name in a publisher statement as
well
as
a publisher access point is not redundancy at all. They are two
different
things. Likewise with series, statement of responsibility, etc. (For
example, WorldCat Local shows how horrible it is to confuse the
different
properties and functions by getting rid of the statement of
responsibility
and then trying to replace it with a "made up" statement taking some
of
the
data appearing in 1XX/7XX fields.)
So yes, it is possible--and necessary--to separate description and
linking/access. (That is, when we're talking about access in terms of
authority-controlled elements.) We used to do it all the time; AACR2
codified it. We're in danger of losing what we gained in the move
from
AACR to AACR2, if don't keep in mind the essential differences between
elements. It's happened in WorldCat Local, in some CONSER standard
records, and elsewhere. Turning everything into data elements is a
good
thing, as long as we remember what those data elements are for and
don't
assign functions to them that they can't fulfill.
Kevin
Kevin M. Randall
Principal Serials Cataloger
Bibliographic Services Dept.
Northwestern University Library
1970 Campus Drive
Evanston, IL 60208-2300
email: [EMAIL PROTECTED]
phone: (847) 491-2939
fax: (847) 491-4345
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
