[It appears that my recent message was empty when sent. I apoligize. What I attempted to send follows] On Mon, 7 Nov 2011 11:05:14 +0100, Bernhard Eversberg <e...@biblio.tu-bs.de> wrote:
>07.11.2011 10:55, Jim Weinheimer: >> What then >> will be the purpose of ISO2709 except one: to transfer a catalog record >> from one library catalog to another? >> >I know of no other purpose. But be that as it may, my point is that >even for this function, it is no longer technically necessary. >For all intents and purposes, MARC may live on forever without >the need to deal with ISO2709. It is technically obsolete, but we >need not care. >Can anyone please prove me fundamentally wrong, or confirm what I say? According to my small experiences in the years before I used modern library systems, when I was trying to extract data from MARC files (e.g. to carry out authority control in systems that didn't have authority modules, before proceeding to print catalogue cards), raw MARC data in communications format was a beast, and I wasn't nearly programmer enough to write routines to deconstruct it! 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. The success of these operations depends on the consistency of the records available. The complexities arise from the complexities in the data we work with, the consistency of our markup (recorded in MARC tags and subfields, a number of which are very specific and don't occur very often, but are applied to specific purposes when they occur, e.g. 254) and sometimes the inconsistency, as when we don't distinguish parallel tiles or alternative titles from other title elements. Those inconsistencies are not so much caused by MARC, certainly not by MARC in ISO2709 format; they result from the belief that specific codes for those elements cannot be created because the coding structure is already full; which is only half true. Now, if what you want is a data storage which can be queried and reprocessed directly, without going through conversions to and from ISO2709, that's something to discuss in its own right; but the tools to translate data between ISO2709 and tabular form do exist, and they operate "on the fly" within their own systems. For working outside a library system, MarcEdit is one commonly used; for querying specific bibliographic elements it's far from simple. But even Voyager, the ILS providing LC's catalog, supports searches within specific MARC fields and subfields of the LC bibliographic database. Maybe the problem is that there's no universal bibliographic database that isn't MARC-based? And therefore one has to deal with MARC with its inconsistencies and idiosyncracies? I have no solution to that problem; the weight of our history is a considerable obstacle when it comes to trying to do something different. Hal Cain, who acknowledges his knowledge is incomplete and liable to correction Melbourne, Australia hegc...@gmail.com
