I’ve been having a long discussion (years!) at this point with Jim Weinheimer about RDA. Here’s my latest volley, which I thought worth posting.
If I understand Jim’s position correctly (which I may not, perhaps consider this an argument with someone who isn’t Jim who holds this position, in case I’m misrepresenting him), Jim thinks RDA is an expensive sidetrack, and what we really need to be doing is simply start using MarcXML instead of ISO-2709 Marc21, and then gradually enhance that MarcXML with new features we need, freed from worrying about making them compatible (“round-trippable”) with ISO-2709 MARC.
So, okay, let’s carry that through and see where it gets us. Okay, we add a new thing to MarcXML (a concrete example would make this narrative more comprehensible, but one isn’t coming to mind at the moment).
Where do the instructions go to catalogers to tell them how to fill out this new thing?
They can’t really go in AACR2, because AACR2 isn’t written in terms of data elements, it’s just written in terms of narrative, really.
I guess they could go in MARC documentation? Or LCRI’s or something? But this mish-mash of instructions and documentation in multiple places part of what makes it really expensive to create and use our data, as well as really confusing and complicated to make changes to it in ways everyone understands.
The most important thing that RDA does (or tries to do), is provide cataloging guidance/instructions in terms of data elements, not narrative text. Then, when you want to add a new data element, everything matches — you can add a new data element in the RDA vocabulary, you can add instructions on how that data element is filled out and what it means in the RDA instructions, and you can be very specific about exactly where to find that data element in MarcXML, or any other serialized data format. You want to switch to a new serialized data format, but be sure that it has the same meaning that was in the old one? No problem, you just decide where each of those data elements go in the new format, and you know it carries the same meaning. You’re a programmer looking at data, and you want to know what that data means and what instructions were used to create it? No problem, you just figure out what data element in the RDA vocabulary it is, and then you can look up RDA instructions on that element.
This rationalization of our data is crucial for being able to have software make sense of our data in consistent ways, and encode data so it can be made sense of in consistent ways. And it’s crucial for allowing the cataloging community to actually maintain their standard practices in a coherent way, such that they can look at what they do and understand the implications of changes, and such that they can communicate what they do to new catalogers or to anyone else in a reasonable way.
And that’s why RDA is very important, and “just use MarcXML and enhance it” is utterly insufficient.
Now, if RDA fails at making things as clear as this, then it needs to be improved. But it’s absolutely vital that we try to make things clear like this, and RDA is apparently the best we are able to do as a first try — and “just put things in MarcXML” simply doesn’t get us anywhere. Not if you want cataloging to really be a rational professional enterprise, not just a mish-mash of inherited wisdom written down in different ways in half a dozen places and targetted at creating good cards for a card catalog.