On 25/09/2012 16:32, Brenndorfer, Thomas wrote:
James, you’ve missed my main point—
Manual intervention occurs already.
It has to – system upgrades often involve invoking new features, sometimes based on long stagnant data.
Systems migrations to entirely new systems means rooting out all the workarounds and redoing a lot of work—it’s inevitable, but generally often worth it.
New MARC codes have come out on a regular basis over the years, some of which require fixing old records (or waiting for them to gradually disappear as the collection churns over).
Authority records and access points get changed all the time, and this requires a set of procedures and tools to incorporate them successfully. My current setup includes vendor cached copies of the LC authority files, and instant automatic linking and overlaying.
Manual intervention put pressure on getting better tools. The tools I have today to do large scale batch updates are light years ahead of what I was using 10 years ago.
Plus, a lot of what is in RDA is a simply a transfer of what is in AACR2 (perhaps too much of a dump). Many of the same options will continue as before. Libraries that used $4 relator codes will continue to do the work, but may convert the date to the new designators.
But, like the fixed fields, the groundwork is being set up for better things. Unlike in previous systems, I now make extensive use of fixed fields. I would never go back to the old way of doing things, with all the typos and makeshift local fields and clunky batch change tools.
There will never be anything as complex as AACR2/MARC for cataloging. Students learning RDA generally find it easier, and students who’ve learned how to build databases find it a breeze, as it is written in a more universal language that doesn’t depend on card catalog jargon. (True, there’s still jargon, as with any technical standard—but at least one can point to generic texts on database modeling and discern why RDA and FRBR are structured the way they are).
I understand about manual interventions and I discussed them at some length in my podcast. But as I pointed out there, using different words: there are manual interventions and MANUAL INTERVENTIONS. If the relator codes are to be made useful, there must be a number of MANUAL INTERVENTIONS, touching a huge percentage of all of our records. I don’t know what level of staff it would demand. Doing it automatically is only possible in theory and must be demonstrated in reality before any assumptions there could be made. When I consider what would make the relator code “editor” useful for searching, I marvel at what an incredible undertaking that would be.
There are always disputes on where an organization’s resources should go, and these disputes become especially tense as budgets become scarce. As a library user, would I prefer that resources be spent on updating the records with relator codes, or buying more new materials and cataloging them quickly so that I can get at them? A no-brainer, I think.
I have also never said that AACR2 shouldn’t be changed. Of course it should. The problem is, there is still not enough information to know how it should change. The FRBR structure seems obsolete to me, although yes, there a few nice things, but modern faceted indexing has obviated any “need” to manually create the FRBR format structures. I have made several suggestions for rule changes, such as eliminating single main entry(!), also combing through the rules to eliminate the rules clearly based on alphabetical browsing, such as the rules for cross-references for permeated names of conferences and other corporate bodies, perhaps even for personal names, but many have protested against these suggestions. Still, others would have several suggestions themselves.
I still like Michael Gorman’s idea of simplifying the rules to an absolute minimum and then allowing various groups (maps, images, theology, law, Arabic and so on) to make additional rules for their own communities, thereby modularizing the entire system. This way, a bare minimum amount of standardization would be achieved for basic interoperability and we could–in theory–work together with a certain amount of freedom. What would that mean in reality? I don’t know, but it seems as if it would be a promising road to try.
RDA is not the only choice to move forward! There are many options.