This thread has turned out to be very revealing in many ways. I feel compelled
to point out that our cataloging rules are *supposed* to be centered on the
user (or the patrons, or the public, or the readers, or however someone prefers
to label them). In fact, in the past I have had to endure
On Thursday, December 09, 2010 3:27 AM, Weinheimer Jim wrote:
This thread has turned out to be very revealing in many ways. I feel
compelled to point out that our cataloging rules are *supposed* to be
centered on the user (or the patrons, or the public, or the readers, or
however someone
Hi
We are studying RDA and find it sometimes difficult to understand why some
fields or subfields are a core-element in RDA.
For instance:
-Statement of responsibility relating to title proper in some
descriptions is the repeating of the name of the author in a specific field of
Both AACR2 and MARC21 have been called straight jackets.
We find RDA to be much more of a straight jacket than either.
For example, recently a separate item (offprint or reprint?) was
described as 730 02 $iContained in (work):$aJournal ...
That is a bald faced lie. Talk about forcing square
I can't BELIEVE I'm defending RDA, but ...
Rosa Matthys said:
-Statement of responsibility relating to title proper in some descrip=
tions is the repeating of the name of the author in a specific field of 'st=
atement of responsibility' not relevant, all information can be provided in=
the
SLC PRACTICES INCORPORATING RDA
J. McRee (Mac) Elrod 8 December 2010
[Local SLC practices in brackets]
These provisions do not take effect until RDA records are received
from national cataloguing agencies.
In
On 12/9/2010 11:22 AM, J. McRee Elrod wrote:
Rules should be made for patrons, not for machines.
The machines exist to serve the patrons too. No patron in a a 2010
library (Or at least 99% of libraries) looks at the records you are
creating _except_ through machine interfaces.
If you
Can anyone point to documents that describe the reasoning behind the
selection of core elements for RDA? I admit I haven't read
*everything* on the RDA pages so I may have missed some obvious
discussion that is chronicled in the comments documents.
Also, has anyone made up a list/table of
Karen:
Copying from the RDA rules from the RDA Toolkit: (apologies for length. I
will also just say that I don't think core is at all complete enough to
help patrons really identify and select what they want, but that's
editorializing. Rules below)
0.6 Core Elements
0.6.1General:
Certain
Yes, I agree with you Jonathan. *Both* the rules and the machines are
tools to try to provide services for patrons. Just the means to an end.
I think a lot of the confusion arises because of the very varied
environments where our data are living. It's not always clear where the
problem
On Thu, Dec 9, 2010 at 11:06 AM, Karen Coyle li...@kcoyle.net wrote:
Also, has anyone made up a list/table of core elements by format?
Not that I'm aware of, but LC has a concise list of RDA Core Elements
for starters:
http://www.loc.gov/catdir/cpso/RDAtest/coreelements.doc
LC's core
Hi Karen -- the background on the selection of the Core elements is
here: http://www.rda-jsc.org/docs/5chair15.pdf
We've been told the core elements were selected as core because they
rank in high value according to the FRBR user tasks (that value matrix
is at 6.1 in the FRBR document:
Jonathan Rochkind said:
The machines exist to serve the patrons too. No patron in a a 2010
library (Or at least 99% of libraries) looks at the records you are
creating _except_ through machine interfaces.
We find MARC21 coding makes our records quite machine friendly. In
fact, MARC means
Mac wrote:
snip
The relationships among authors and works, manifestations and works,
are for too varied to be expressed in set vocabularies. Creating
them seems like a Medieval exercise in theology.
/snip
Jonathan Rochkind wrote:
snip
If catalogers are unwilling to create records that can be
MARC is machine readable but only to a limited point. A classic example is
the 300 field, which I go into some depth in
http://dltj.org/article/defining-metadata-accessibility/ from an accessibility
and machine readability point of view:
it is the difference between ix, 74 p. : ill. ; 23 cm
15 matches
Mail list logo
