What is required to make this sort of addition useful is people who are
willing and able to add the information. The rare materials cataloging
community is used to doing this sort of thing, both for the local catalog
and to existing records in OCLC. I would suspect that some music
libraries
If I recall the discussions, the original thought of coding 'r' for RDA
in the LDR/18 exposed the Anglo-centricity of the LDR/18 value 'a' for
AACR2, when all of the other national cataloging codes were relegated to
040 $e. Also working from memory, RDA records that are not ISBD
punctuated will
Deborah Fritz pointed out to me over coffee at ALA that there is a
significant difference in granularity between the RDA elements, as
defined by JSC, and what we have today in MARC. I will try to give one
simple example here, using Title Proper, but I'm sure there are many
others. The
I don't know the answer, but part of this issue is the ambiguous roles
of MARC vs. AACR2 in our legacy environment. MARC has _not_ simply been
an 'exchange format' for some time, it has come to be a 'content
standard' competing with (or extending in a complementary way, depending
on your
I think the answer to both questions is yes and no. In some areas the
granularity is sufficient, in others not. For example, MARC does not provide
sufficient granularity for the relationships between resources in RDA, most of
which must be represented by free text in subfield $i of fields
I have always been bemused by the jargon we use. By granularity, I assume
one means detailed access points.
On Thu, Jan 28, 2010 at 9:39 AM, Ed Jones ejo...@nu.edu wrote:
I think the answer to both questions is yes and no. In some areas the
granularity is sufficient, in others not. For
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Gene Fieg
Sent: Thursday, January 28, 2010 12:52 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] RDA and granularity
I have always been bemused by the jargon we
If $n and $p are important distinctions, shouldn't they in fact _be_
referenced by RDA? And, really, shouldn't they have been referenced by
AACR2 all along too?
Theoretically, AACR2 was not tied to MARC. RDA tries to make this even
more explicitly clear. It gives guidance for filling otu
These granularity issues are not new. The granularity of MARC does not
match the granularity of AACR2/ISBD.
The most glaring case of MARC being insufficiently granular is the well
known case of the 245$b being required to code for the parallel title
(AACR2 1.1D), other title information (AACR2
At 01:05 PM 1/28/2010, Jonathan Rochkind wrote:
If $n and $p are important distinctions, shouldn't they in fact _be_
referenced by RDA? And, really, shouldn't they have been referenced
by AACR2 all along too?
They *are* referenced in RDA (and AACR2), which provides instructions
for
Well, as John Myers said previously, and I agree:
I am afraid that these standing granularity issues between the various
descriptive standards (AACR2, ISBD, RDA, DACS, etc.) and between each
descriptive standard and the communication standard (MARC or MARC21) are
going to play havoc with the
John Attig wrote:
Subfields $n and $p are an example of this. I
would hate to lose these distinctions; specifically, they relate to
ISBD punctuation specifications and -- as noted in MARC 2010-DP01 --
this content designation does allow ISBD punctuation to be supplied
for display rather
I thought that $n and $p are in 245 because they're defined as uniform
title elements, and 245 is unfortunately considered to be both the
descriptive title and the uniform title when coincidence allows. One
value of $n and $p subfielding in uniform titles is that you can
authorize headings
Quoting John Attig jx...@psu.edu:
Again, they are mentioned in the guidance, but not as elements -- for
the reasons given above. The guidance is not *independent* of the
record format in which the data is encoded -- choice of an encoding
format is a necessary precondition to recording the
14 matches
Mail list logo
