From my perspective, the fact that catalogers "just do" things that
aren't in fact documented anywhere is a really big problem. Makes it
hard for new catalogers or metadata-creators (one of the stated goals of
RDA is to make metadata creation more accessible, both inside the
library community and outside), makes it REALLY hard for software
developers to figure out what's in the records, makes it unreasonably
challenging for those who do choose to add the data to be consistent.
But I agree with John in general. Certainly, when the standards are
insufficient metadata creators are always free to add extra stuff not
provided for in the standards. But our goal should be to make standards
that are sufficient, of course. Equally important is to make standards
that can be changed and enhanced with ease--this is about our process
itself as well as about the technical design of the standard (some
standards technical design provides for extensibility right off the
bat). If it's discovered that a standard is not sufficient, it should be
much easier than it is to extend it to cover the new case, so the people
adding the 'extra' stuff can do so according to actual documented and
agreed upon practices, rather than unwritten rules passed from cataloger
to cataloger.
Jonathan
John Attig wrote:
At 10:58 AM 5/9/2008, Karen Coyle wrote:
John, I agree with you that we need both pieces of information, but how
can this be part of our data if it isn't included in the cataloging
rules?
I don't disagree that this should be provided for in RDA.
This is what concerns me: that there seems to be an assumption
that data will be available that isn't being accounted for in RDA. As
you say: "Apart from RDA..." Where will this data come from if not from
the cataloging process?
There is no provision in AACR that supports the use of 752 that I
describe, and yet catalogers -- at least in some contexts -- do
provide the data. I'm not sure that we need to assume that any set
of cataloging rules defines the limits of what can be included in our
cataloging records.
And why should our cataloging rules ignore data that we know we need?
The trick is to make a convincing case that we do need this
data. Apparently this has not yet been done.
John Attig
Authority Control Librarian
Penn State University
John Attig wrote:
At 09:27 AM 5/9/2008, Karen Coyle wrote:
Adam L. Schiff wrote:
At present, the instruction in RDA is to take and record what you
see.
In other words, true transcription of what you find, with no
abbreviation. However, if abbreviations are on the resource, then you
will record them the way they appear. If the higher jurisdiction of
the place is not present, it does not get recorded in the place
element. Instead it will be given in a note.
Which, of course, makes it useless for any machine processing, such as
re-organizing a retrieved set by place of publication or providing
a way
for a user to Find (FRBR user task) items published in a particular
location. It seems that when it comes to Find, the rules have a
pre-conceived notion of what users can ask for.
And in case you think that this isn't a legitimate search, I had
reason
to do exactly this search the other day, and was not successful.
The way to support this functionality, which I agree should not be
dismissed out of hand, is not to change the conventions for recording
the place of publication -- whose function is primarily one of
identification, based on what appears on the item -- but rather to
define a relationship between the resource and the place in which it
is published, using the Place entity to provide a consistent form for
access, as well as variants.
Apart from RDA, I would note that many special collections libraries
currently use MARC field 752 to provide structured, controlled access
to place names as a means of creating an "imprint" file for their
holdings. The point is the same: we need a controlled access point,
not a descriptive data element, in order to provide consistent access
to place of publication.
John Attig
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[EMAIL PROTECTED] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
