Posting to RDA-L
On Tue, Nov 8, 2011 at 7:01 AM, Hal Cain wrote:
However, once I began to see how competent systems handled MARC, it became plain that what they were doing was basically to create a matrix and populate it with the tag values, the indicator values, and the subfield data prefixed by the subfield code. Then the indexing routines read the matrix (not the raw MARC ISO2709 data) and distributed the data into the appropriate areas of the system’s internal table structure. From those tables, I was able, when required, to obtain what I wanted by direct query on the appropriate part of the database. When it was necessary to export a single MARC record, a group of them, or indeed the whole database, the system had routines which reversed the process (and, last of all, counted the number of characters in order to fill in the record length element of the MARC leader). This was extremely burdensome to programmers who came to the game in the 1990s and had no background in early data processing, chiefly of text rather than numbers, but in its time it was pure genius. Nowadays it’s a very special niche, and the foreignness to programmers and designers of the processes involved probably plays a part in keeping us from having really good cataloguing modules and public catalogues; and I can understand the frustration entailed for those who expect to interrogate a database directly.
Bear in mind, though, that using a modern cataloguing module (Horizon is the one I’m most familiar with), I can search for a record on a remote system, e.g. the LC catalog, through Z39.50, and have the record on my screen, in editable form, in a second or two, indistinguishable from a record in the local database. The system’s internal routines download the record in MARC format (ISO 2709, hated by Jim) and build the matrix which feeds the screen display.
This is really a nice description of the problems of ISO2709, Hal. Thanks a lot.
I would like to clarify one point however: do I hate ISO2709 format? I can answer that honestly: no. It served its purpose well for the environment it was born into. That environment changed however, and we need to face up to that. If our modern systems (i.e. modern web browsers) worked with the ISO2709 format, i.e. the files that the machine actually receives, then I would be all for it.
Yet, this is not the reality of the situation. Browsers work with a variety of formats, but they work with XML, which gives us some options. Browsers do not work with ISO2709, and I don’t believe they ever will. Therefore, the only systems that can work with ISO2709 records (which is how libraries exchange their cataloging information) are other catalogs, and that automatically restrains us from participating in the wider information universe. As a result, in my own opinion, hanging on to ISO2709 borders on the irrational since we automatically limit the utility of our records, thereby limiting ourselves.
MARCXML has many limitations that I won’t discuss here, but *at least* it is in XML which *can* be used in the new environment. It is much more flexible than ISO2709. For instance, I have mentioned before that I believe we should get away from a *single* main entry–that while a single main entry made sense in the card catalog, it makes no sense in a computerized catalog. Others disagree, but no matter what, I think it is vital that we should have that kind of flexibility.
Getting rid of a *single* main entry would be the equivalent of DC’s <creator> and <contributor> where <creator> is repeatable, thereby creating multiple main entries. It turns out this is much more difficult than merely making 1xx repeatable, since you also have to allow it in the 6xx, 7xx and 8xx, for books *by* Masters and Johnson, for books *about the books* written by Masters and Johnson, for analytical and series treatments as well.
You could do this without too much difficulty in XML, even in MARCXML, but in ISO2709, it would be a relative nightmare because you would have to rework the entire structure, from the directory on down. (This is why the MARCXML principle of “roundtripability”–what a word!–needs to be dropped. Otherwise, we still remain trapped in the ISO2709 format!) Anyway, while it may be possible to rework ISO2709 to such an extent, would it be worthwhile to do it on such an old format?
This is just one example of the relative inflexibility of ISO2709, but there are many more.
Still, I don’t hate ISO2709. It served its purpose admirably, but it’s like the horse and buggy. I’m sure nobody hated horses and buggies after the automobile came out, but eventually, if it turned out that Dad and Grandpa refused to get a car when everybody else had one and the advantages were plain for all to see, Junior very possibly would have wound up hating the horse and buggy he was forced to use.