Aha, this makes more sense, thanks for explaining. Still not sure what
I think, but it makes more sense than what I originally mis-understood.
Jonathan
Ed Jones wrote:
RDA is meant to appeal to a variety of user communities, and some of
them may opt not to apply some of its provisions. RDA 1.8 is one such
provision: it states that certain elements "may" be used for both
purposes; to me, this means that they also may not. It moves the
decision to the level of the particular community implementing RDA. I
don't see it as that big a deal, but maybe I'm missing something.
To give a scenario: My community decides on the rigid separation of
description and access and receives a shipment of records from a
community that applies RDA 1.8. On these records the descriptive
elements are doing double duty, so for my own system I automatically
massage the records to generate (1) a controlled access point field and
(2) a provisional authority record from the data in each double-duty
field (e.g., in MARC terms, generate a 240 from a 245 or an 830 from a
440). The records can now enter my system and conform to my
implementation of RDA (with the description in unindexed 245 and 440 and
access points in corresponding authority-controlled 240 and 830 fields).
I would be more worried if RDA talked about generating description from
access points--Kevin's example from WorldCat Local--but RDA 1.8 is a
one-way system: only generating access points from description
(specifically titles, which are fairly straightforward) and not vice
versa.
I'm not disagreeing with the end. I just think RDA as written is
capable of accomplishing that end.
Ed
-----Original Message-----
From: Resource Description and Access / Resource Description and Access
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Rochkind
Sent: Tuesday, May 06, 2008 1:41 PM
To: [email protected]
Subject: Re: [RDA-L] RDA Vocabularies Project
By ignoring RDA and coming up with their own guidelines for creating
metadata?
I mean, there's nothing to prevent a given implementation community from
ignoring RDA entirely and doing whatever they want. But that sort of
defeats the purpose of RDA if we're _counting_ on that, no?
Am I missing something?
Jonathan
Ed Jones wrote:
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
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
