I do think that the ideal situation is one where one has both
human-readable data and identfiers for many of the data elements. That
way you have the best of both worlds. Look at CCO, many of the
instructions also follow this path. I think it is a good thing for the
rules to say that this is a desirable state when possible.
But remember that this is not always going to be possible. For one
thing it will take more time to input this information--and how many
times over the years have you heard griping about having to input the
"redundant" information in fixed fields (not that this information was
ideally coded, but the impulse for machine processing was there).
Administrators will not see this as a simplification.
Secondly, there are many small libraries and museums out there who use
software that doesn't really support the MARC format, let alone some
multilevel structure with both eye-readable and coded fields. And of
course there are metadata projects with templates being input into by
relatively untrained staff. I already think that RDA has gotten too
complicated for these communities, and mandating double fields for most
elements just is not going to work in these environments. That's why
i'm shocked that the RDA outcomes says they are adding the Statement of
responsiblity to the core fields. Do you all seriously believe that a
small museum or metadata project that is working in FoxPro or Excel or a
homegrown form or proprietary software that has at best a field for
title and maybe one or more fields for variant titles is going to input
a statement of responsibility? Where will they put it, in the title
field? (where it will be in the title index). In a note? (probably the
best solution but it takes time). And statements of responsibility for
videos are particularly lengthy and time consuming. And there is the
Conser Standard Record. Do you think this is going to go away?
And i think that mandating either eye readable or machine processable
info (i.e. making one mandatory and the other optional) is not really
going to work in all cases. Small institutions with limited fields and
not much technical infrastructure will have to go for eye-readable
strings or their catalogs will not be functional within their host
institution, while metadata projects with more technical support would
probably go for the identifiers.
Greta de Groat
Stanford University Libraries
Jonathan Rochkind wrote:
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
