One of the points which Bernhard Eversberg has made about XML is:
"The difference is the language-tied tags. They are not international.?
Only numbers are. Terminology chances, and then there you are with?
your nice outdated tags. Numbers resist change.?"
His point then refers to XML code-fragments like
<datafield tag=
<subfield code=
I am currently in favor of allowing bibliographical records to consist mainly of written human language.? However, I agree with Eversberg's critique of XML.? I would posit that?the library catalog not only is, but also should be:
(1) written in a particular human language,
(2)?possessing a deep structure written in the same language as its surface structure.
For human languages Noam Chomsky posited?a concept of deep structure and surface structure, and this has clearly had a pervasive influence on every area of computer programming and application, although the history of this influence has not yet been written.
But recently, as a casual perusal of some linguistic texts strikes me, American linguists have been remarkably fuzzy about whether the deep structure of French is French, or whether the deep structure of German is German.? When they print a representation of deep structures for any language, the deep structure as portrayed tends to end up containing a high amount of English.
The casual, never explicitly stated, assumption that the deep structure of all languages is English is deeply jingoistic and anti-global.? The debased meaning of "globalization" is "make everything American", but the true meaning of globalization is, in part, "allow different human languages to coexist."
XML is, from what we have seen, highly English-based.? For this reason, it seems to me to be an unlikely candidate for the deep structure of a library catalog of a French, German, Spanish, or Chinese library.
When we consider the language of a library catalog, it's important to bear in mind the difference between the transcribed elements of a bibliographic record and the describing elements.? (The fact that both groups of elements are traditionally considered part of "descriptive cataloging" is not relevant here.)? The title is a transcribed element: the title of a book (and also the statement of responsibility) will almost always be in the same language as the book itself.? Nothing in this e-mail should be construed as a claim or recommendation that American libraries should not include books in German, or that German libraries should not include books in English.? But the describing elements of the bibliographic record -- including the notes and the physical description -- are in the language of the catalog -- and they should be in German in a predominantly German-speaking country, in English in a predominantly English-speaking country, and multilingual according to some consist
ent and predictable pattern in a country deeply divided linguistically.
So I agree with the above-quoted piece of Eversberg's criticism of XML.?
He sees hope in numerical encoding of metadata, but I am somewhat leery of arbitrarily encoding meanings?into numbers, unless the numbers are backed up by a standardized system of mnemonics.
OCLC has always used little English abbreviations (mnemonics) to help catalogers remember the meaning of different elements in the MARC fixed field.? My position is that these mnemonics have not been standardized at the level at which they deserve to be standardized -- they should be elevated to the dignity of being part of the MARC standard -- and that they have been underutilized -- there should also be MARC-standard mnemonics for every one of the MARC variable fields.? To me, a single set of numeric codes together with?multiple?standard sets of mnemonics -- one set of MARC mnemonics for each human language used as the language of library catalogs in at least one nation -- might be the ideal solution to this part of Eversberg's critique.
MARC's in bad shape because of its era of complacency.? The battle cry of the early MARC era was "we've got to stick together because this has to be a standard; if this is not standardized, it can accomplish nothing."? But for middle-era MARC -- maybe 1985 to 2000? -- there was no battle cry, but it was simply continuously assumed that MARC still could not be constructively criticized.? Now in this decade, we are paying the price for the long period of not criticizing MARC.? There are many things about MARC that are badly in need of fixing.? Two examples: (1) related elements of data are scattered all up and down the variable fields from 001 to 999.? (2) Too many indicators refer to "print constants"; but having?elements which can reduced to a single byte in machine-readable cataloging, and then expanded to a word or phrase in a printed library catalog, is not useful in the context of catalogs which do not exist in printed form.
However, XML is also terrible.? One of its problems is its umbilical attachment to the unacceptable idea that the deep structure of all library catalogs?can be?written in English.
I don't think we should give up on improving MARC.? Perhaps one idea to bear in mind as we consider how MARC improvements might be implemented, would be that instead of thinking in terms of "migrating data", we should be thinking in terms of "gradually propagating changes in data structure through a database."? With the current levels of sophistication available to programmers, there must be ways to allow older and new improved data structures to coexist in the same database.? I'd love to see open communications in which library catalog design people -- descendants of Panizzi -- and database design people exchange ideas about (a) how MARC can be improved and (b) how MARC improvements can be implemented and (c) how individual library system vendors can?incorporate MARC improvements into their upgrades, in ways affordable to libraries and comprehensible to library catalog maintenance people.
Frank Newton
a technical services librarian
Boiling Springs, North Carolina, USA
-----Original Message-----
From: Bernhard Eversberg <ev_at_BIBLIO.TU-BS.DE>
To: NGC4LIB_at_listserv.nd.edu
Sent: Mon, 27 Aug 2007 3:24 am
Subject: Re: [NGC4LIB] MARC structure (Was: Re: Ceci n'est pas un catalogue)
Alexander Johannesen wrote:?
>?
>?
> Hmm. What about XML as a standard is not elegant??
Indeed it isn't. A format that gobbles up more bytes for tagging than?
the data it wraps cannot be elegant. Even gift wrappings nowadays have?
to be ecologically sound.?
?
>?
> What, exactly, is the difference between ;?
>?
> <record>?
> <datafield tag="245" ind1="1" ind2="0">?
> <subfield code="a">[Interview with Keith McCance]</subfield>?
> <subfield code="h">[sound recording] /</subfield>?
> <subfield code="c">[Interviewer : Bronwyn Benn].</subfield>?
> </datafield>?
> </record>?
>?
You don't see what I mean? 31 extra bytes for every subfield rather than?
2? Where is this more elegant than?
?
245 10 $aInterview with Keith McCance$h[sound recording]$c[Interviewer :?
Bronwyn Benn] ??
?
> and ;?
>?
> <record>?
> <title>?
> <main>Interview with Keith McCance</main>?
> <media>sound recording</media>?
> <responsible>Interviewer : Bronwyn Benn</responsible>?
> </title>?
> </record>?
>?
The difference is the language-tied tags. They are not international.?
Only numbers are. Terminology chances, and then there you are with?
your nice outdated tags. Numbers resist change.?
?
B.Eversberg?
________________________________________________________________________
Email and AIM finally together. You've gotta check out free AOL Mail! - http://mail.aol.com
Received on Mon Aug 27 2007 - 11:48:15 EDT