Blog comment to more on the point of RDA Bibliographic Wilderness
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.