Posting to RDA-L
Jonathan Rochkind wrote:
I don’t see any significant increase in flexibility to share Marc records by ‘switching’ to MarcXML. Am I missing something? What exactly would be the advantages of ‘switching’ to MarcXML?
When we talk about MARC as it is used by libraries today, we cannot separate it from the underlying ISO2709 format, since this is the primary (and still the only?) means that we transfer records from one catalog/database to another. It is the ISO2709 format that is completely inflexible. What we see on our computer screens when we catalog something is *not* the MARC format that we are really working with.
Originally, library records were stored, searched, displayed, etc. from the ISO2709 format, but as relational databases appeared and XML indexes such as Lucene and Zebra appeared, the storage of records took on different forms, but the *transfer* of the records has always remained in ISO2709 format, that the computers compile at the time of transfer using Z39.50. So, if we look at http://tinyurl.com/6hfuqjf, and at the bottom, click on “Select Download Format” to one of the MARCs, save it and open it in Notepad (or whatever), this is what is transferred. I am 100% certain that this is not how the record is stored within the Voyager database at LC, but when a library wants to transfer the record into their own catalog, this is the method: by compiling that information into an ISO2709 record.
The record itself:
01468cam a2200325 a 4500001000800000005001700008008004100025035002100066906004500087955012200132010001700254020003600271040001800307043001200325050002300337082001500360100002900375245011500404260005600519300003500575504006400610600006300674650005000737650005000787650003300837856009500870856008700965920004101052991004901093 1182910 20041208175945.0 971106s1998 caua b s001 0 eng 9(DLC) 97043755 a7bcbucorignewd1eocipf19gy-gencatlg apc14 to ja00 11-07-97; jk27/jk15 (desc) to subj. 11-13-97; jk14 to DDC 11-17-97;aa05 11-19-97; cip ver. jb09 09-22-98 a 97043755 a0520212010 (cloth : alk. paper) aDLCcDLCdDLC ae—— 00aNB623.C2bJ64 1998 00a709/.2221 1 aJohns, Christopher M. S. 10aAntonia Canova and the politics of patronage in revolutionary and Napoleonic Europe /cChristopher M.S. Johns. aBerkeley :bUniversity of California Press,cc1998. axvii, 271 p. :bill. ;c27 cm. aIncludes bibliographical references (p. 237-259) and index. 10aCanova, Antonio,d1757-1822xCriticism and interpretation. 0aArt patronagezEuropexHistoryy18th century. 0aArt patronagezEuropexHistoryy19th century. 0aNeoclassicism (Art)zEurope. 423Contributor biographical informationuhttp://www.loc.gov/catdir/bios/ucal052/97043755.html 423Publisher descriptionuhttp://www.loc.gov/catdir/description/ucal042/97043755.html a** LC HAS REQ’D # OF SHELF COPIES ** bc-GenCollhNB623.C2iJ64 1998tCopy 1wBOOKS
This is completely inflexible. The first 5 places 01468 define the length of the entire record. The record cannot vary even 1 character from this length, otherwise it will break. The horrifying string of numbers afterward define the lengths of each field, counting the indicators and subfields. In fact, the field numbers themselves, i.e. 100, 245, 300, etc. are embedded inside this horrifying string of numbers and are separated from their text fields below. So, for the heading of Canova as subject, somewhere in that number string is the “600” followed by the length of the string after that, including the indicators and subfield codes, plus “Criticism and interpretation”.
For a long time there was no problem with a completely inflexible record like this since the whole idea was to transfer entire catalog cards from one library system to another. That is no longer the case at all today, and hasn’t been for quite some time now. How can that format above work with linked data in various ways without breaking everything? How would the FRBR entity structure work in ISO2709? Because it must work with ISO2709 since that is how our records are transferred.
So, while we can do anything we want *within* our own catalogs, making all sorts of wonderful things, they can’t be transferred anywhere else because of this obsolete transfer format, i.e. without considerably reworking it. How could this work with linked data, bringing in information from other places? I compare it to working at Hoover Dam, filled to teeming with fresh water that we keep making sweeter and cleaner, while there are all kinds of towns out there wanting our water desperately, but the pipes out of the dam only have a capacity of 1 or 2 gallons per minute and they leak like sieves. My water ends up useless.
While I won’t argue that it may be possible to rework the ISO2709 format to work with linked data, why should we even think about it when we have XML? It would be completely wasted work. Nobody without an ISO2709 parser would even consider using such a format. This is why I mentioned switching to MARCXML, that is for *record transfer*, which could be done with the least disruption. For instance, the FRBR/RDA structures would become more feasible, if it were desired (!). Internally, each catalog can be structured however the designers want it, but for record transfer, it should be MARCXML.
This could be done completely behind the scenes with most not even noticing a difference–at least at first–and while there are problems with MARCXML, switching to any kind of XML format would open a wealth of possibilities.