more on the point of RDA

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.

4 thoughts on “more on the point of RDA

  1. First, I would like to say that I have enjoyed our private email exchanges since I have learned so much from them.

    My basic idea of suggesting XML in favor over ISO2709 is, in short, we are going to have to switch to XML someday anyway since XML is the language of the web. There is one use, and one use alone, to ISO2709, and that is to transfer complete records (i.e. catalog cards) from one library catalog to another library catalog. The only difference is that the cards are not printed out now. Therefore, I see absolutely no reason to keep ISO2709 and many reasons to get rid of it. The quickest, lossless method would be to go to MARCXML, but I have admitted this may not be the best for the public, and perhaps MODS or even DC simple would give developers at least something to work with, compared with what they have now, which are ISO2709 records that they need to process in various ways before they can be used. Still, let’s offer many formats instead of only textual ones and ISO2709. Plus, so long as we follow the “roundtrippability” (quite a word!) of MARCXML-ISO2709, we will never be able to grow beyond the limitations of ISO2709, which was designed to create cards.

    I believe that for Jonathan though, the problem is not so much ISO2709, but MARC itself, and this is where I think we disagree. This is probably because I am a cataloger. So, for example, when he writes: “Where do the instructions go to catalogers to tell them how to fill out this new thing?” and then he mentions how difficult it is to use the documentation. I think this is a misapprehension of what the task of cataloging is.

    Cataloging is the intellectual task of taking a resource, describing it using standard methods so that the description means the same thing to everyone (the basic idea of ISBD), and then ensuring that description can be found in various ways–also reliably–within a greater intellectual framework. The description and access points are then placed in whatever tool you have for people to use: a card catalog or a database.

    Cataloging is *not* filling out forms–this is only the “instantiation” of the catalog record while it is in the process of taking on a realized form, in other words, it is data entry. In FRBR terms, the “catalog record” first takes place only in a cataloger’s mind (work), then data entry (where it becomes an expression), the view of the record in a catalog (manifestations/items). In more realistic terms, I compare it to Plutarch’s example of watching a carpenter work and concluding that the job of a carpenter is to saw boards and pound nails, but in reality, you’ve missed the real meaning of what the carpenter is doing: the carpenter builds homes for people to live in, and places of business for people to work in. Returning to cataloging, it is easy to mix up the task of data entry with the task of cataloging.

    Therefore, cataloging is a logical process where one part logically follows from another. For instance, the very first thing you must do when cataloging is to determine something called the chief source of information. This is a strange idea for the untrained, yet the rest of the description and even some access points are based on this. Many times, a different chief source of information can result in a radically different description and access points so it is important that everyone, so much as possible, start from the same “chief source of information”.

    So, while it would be nice to be able to include “everything” on a topic in the rules, e.g. form of name of corporate body, but that is difficult to do because so many procedures rely on so many earlier decisions, in this case, the form is normally based on the form found on the chief source of information of one of its own publications. From this one example, we can begin to see how cataloging decisions are based on other cataloging decisions and should suffice to show that the job of cataloging is not filling out forms.

    Still, saying that the problem is with complex documentation seems a little strange to me, but OK, I’ll go along with it. There are many options for documentation today. For example, when I created the Cooperative Cataloging Rules Wiki, Alexander Johanssen suggested that, instead of a wiki, I should use DocBook, which I had not heard of. Although I chose the wiki, I did it because I wanted to get something useful out there for people more or less quickly and did not want to spend time on learning something completely new, but when I saw DocBook, I realized that it was a much better solution since it is completely in XML and so allows complete freedom.

    If people believe the problem of documentation is so difficult, perhaps the CCR Wiki community could start thinking in terms of DocBook for the rules and opening it up to the wider community.

    Reordering the current rules, bringing them together on a wiki or Docbook-type solution, would solve what you mention. I see no reason for creating an entirely new rule set and changing some rules in weird ways in the process.

    In my own opinion, the underlying problem is not with the complexity of the rules, which are complex not to ensure employment for catalogers, but because the materials we receive for cataloging are indeed complex. The *really* hard job is to get people to actually follow the rules in the first place, no matter which ones we choose, thereby assuring some level of standardization, as I discuss in my latest podcast.

    But that is another topic.

  2. Jonathan,
    I have a question for you that kind of works from both of these last two posts. RDA looks at things as data elements, and the fact that MARC won’t do it is a realization that has been definitely becoming more evident to me as you describe many of the hoops through which you have to jump to make things work in your systems. Has anyone tried to create something that does look at creating a record based on data elements like RDA does without limiting themselves to the burden of our legacy systems? I’d love to see the potential of RDA at least begin to be realized. As a cataloger and one of the RDA testers, I truly began to understand how much MARC is holding it back, not just from its full functionality, but from its full comprehension by catalogers. (A tentative generalization I’ve come to based on my own experience and that of those around me is that catalogers have a hard time visualizing things just conceptually. Much of the confusion is because they can’t see it in concrete terms, so the ILS’s are REALLY holding us back.)

  3. I second Melanie’s comment. MARCXML may be the “quickest, lossless method,” but it’s still MARC in XML clothing…lipstick on a pig. I may be in the minority here, but FRBR and RDA make fantastic sense to me. I would like to see a metadata schema comprised of the same entity/relationship building blocks on which they are constructed (I know MODS and MADS come pretty close), and to see that schema employed in an XML format. Then we’d be in a prime position to re-tool our database management systems and user interfaces.

  4. I still get the feeling Jim is missing the point.

    He focuses on the idea that the rules are too complex, rather than picking up on the important point (imo) in Jonathan’s post, which is that RDA allows data to be structured as data elements. AACR2 does not do that, and is therefore insufficient.

    The vast majority of current ILS systems cannot take advantage of the RDA data elements, but that doesn’t mean RDA is the problem (although it DOES have problems). Now that we have at least a beginning of the kind of data structure our data needs, we need to have the systems that can utilize that data.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s