First, I would like to publicly thank Shawne Miksa for her gracious comments. I deeply appreciate her feelings of openness in a delicate situation, and I was sincere when I stated how much I appreciate and admire the dedication and labor of each person who has worked on RDA. Certainly nothing here is against any of them. I only hope I have it within myself to
act in the same way.
Now, some clarifications:
One of the main purposes of the Cooperative Cataloging Rules, as I see it at this point in time, is to give libraries a real, genuine choice(!!) whether or not to adopt RDA when it eventually comes out. I understand current practices very well, being a practicing cataloger for several years in both AACR2 and non-AACR2, non-ISBD cataloging. One of my special interests has been library history, in particular the exceedingly detailed and rather boring methods of library technical services of the past.
A historical view of FRBR provides a case in point. In deference to its stated goals, FRBR says much more about the mindset of some of the most advanced librarians of 20 or so years ago than of any real intrinsic "structure of information." This is not finding fault with anyone or anything--it is simply a recognition of how bound we were (and still are) to library tradition, plus it shows how much we have changed in a mere 20 years. Of course, the phrase "a mere 20 years" also reflects librarian mentality: one that has measured change in terms more reminiscent of geologic eons than of the rate of change today. In today's information society, two or three years ago is simply past it.
Therefore, what relation does the structure of WEMI have to the information tools being made today, i.e., the same tools that did not exist 20 years ago, and couldn't even be imagined back then? The user tasks are even more obsolete. While these conclusions are rather obvious to us today (just find out what your undergraduate and graduate students are doing if you have any
doubt), these changes in information behavior could not have been foreseen back then.
Since many people are still researching how people find and use information, and what people are doing--and will be doing--is definitely in a constant state of transition at the moment, especially when the Google Books agreement will have tremendous consequences for the catalog, changes just as unpredictable as were those 20 years ago, it is my professional opinion that
we still do not know what to change our cataloging rules into. We only know, without any doubt, that FRBR reflects an earlier mentality and therefore, I believe it is highly unwise to change in a direction that we know is obsolete. In any case, we'll still be stuck with an antique, Model-T format for record exchange (ISO2709, and while it is a baby step in the right direction, its MARCXML Doppelganger is merely a reflection of the problems of ISO2709) plus, a mentality that does not want to share our metadata with other communities openly, which is totally out of step with modern realities.
I don't believe this means that we are scared of change--quite the opposite. Why don't we just open up our information for general development by others, for new formats, for use of URIs, taking what they want, just as is done now with all kinds of APIs. This could help us find out what our users really want. Also, we must work with all those other metadata creators out there?
We are not the only ones describing and arranging information resources.
Oh yes! And did I mention financial reasons that don't allow libraries to do the changes anyway? This is another point that can be viewed historically: when FRBR/RDA were being created, libraries were relatively flush with money. For most libraries, it is a completely different story today and will be for the future.
Also, in answer to Benie's query about "scholarly communication" I shall refer to an earlier post of mine about this: https://listserv.nd.edu/cgi-bin/wa?A2=ind0909&L=NGC4LIB&P=R2239&D=0&O=D&T=0&X=56A81B05 59BB7D840F.
(one of my rambling posts. Look at the 5th and 6th paragraphs) I confess this is a real problem, and would love to come up with other terminology for this concept, but I cannot come up with one.