RE: Interpreting MARC

Posting to Autocat
On Thu, 23 Sep 2010 03:14:40 -0400, Hal Cain wrote:

>Well, I see it rather as a need to REGULARIZE the data and distinguish every separate element. RDA can do that, more or less; but RDA in MARC is not going to do it; not unless we formulate and push proposals for changing MARC. Comments of mine elsewhere about adding subfields brought the response that in some fields all available letters have already been used; and when I suggested moving to UPPERCASE letters, which is technically possible, I was told that was judged impracticable for cataloguers to use. Well, after getting abreast of fixed-field coding and $w in authority references, I personally think that is a very bad argument to justify continuing the kind of mishmash of data elements that Jason Thomale so clearly points to.

AACR2 can do that right now, too–you don’t need to change to RDA. There are several problems with MARC, as Jason Thomale’s excellent article points out. One of the problems, as he described so ably, is that programmers are now used to seeing the meaning of the fields within the coding, e.g. <title> as opposed to 245a. But of course, 245a does not mean title, but rather title proper. 245b does not mean subtitle, but other title information. And 245c has that little addition: statement of responsibility, *etc.*, which conceals a whole number of things.

A programmer should not be expected to understand these things, so, even if we changed the coding of 245c to <StatementofResponsibilityEtc> it still wouldn’t solve the problem of parsing everything out “correctly”, as he pointed out very clearly.

Is the solution to implement even more fields, adding all the uppercase letters and perhaps including the entirety of the Unicode character set? I think this would make the problem far more complicated than it is now and the result woud be something much worse and completely unwieldy. UNIMARC “solved” this by making many of their subfields repeatable, while adding a few: 200d Parallel Title Proper, and 200g Subsequent Statement of Responsibility. [See the Descriptive Information Block in the Unimarc Manual at:]

Of course, neither FRBR nor RDA addresses either of these problems, but concluding that everything we have is a mishmash doesn’t make sense to me since we know that what we have made has been very useful for lots of people. So what do we do?

My own suggestion is to not create a problem where there may not be any at all. For example, I haven’t heard of a popular outcry against the problems Jason describes, except from other programmers. On the other hand, I think everybody who catalogs realizes that you are very often mixing title information into statement of responsibility. In spite of this, people have managed all right, and it seems to me that most people just search keyword anyway, since that is what they are used to in Google, online catalogs, databases, youtube, and what have you. That’s what I do and what I have seen everyone do, and then they narrow their search. For example, in Worldcat I can search for “Sister Carrie” by keyword, and then narrow down my results in a whole bunch of ways, by format, by author, by date, etc. In just a second or two, I can narrow it down to books by Dreiser from 1954.

Google has different, but similar options available.
I hope this is how people are searching because it makes the most sense. You search for a huge batch of resources, and *the system* helps you narrow it down. It is lightyears more powerful than the traditional card catalog and is how I tell my patrons to search, if the options are available.

So my own question is: if we assume that these types of methods indicate the future of searching, are the problems that Jason described so well, all that important? I think it is clear that MARC coding has to change, but it should not change for theoretical purposes, but it must change for practical purposes for the future. This–to use Darwinian terms–means it has to *adapt* to the new changes in the environment. What should this be?