I too would like to volunteer to help in developing the "son of
MARC". I would bring to the table 25 years of experience with
MARC systems, beginning at LC as a programmer/analyst in the
original MARC Development Office and now as a consultant and
[log in to unmask]
Johan Cornels Zeeman wrote:
> ----- Original Message -----
> From: "Bruce C Johnson" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Tuesday, April 04, 2000 8:10 AM
> Subject: In "American Libraries"
> > Does everyone agree that we should immediately replace the MARC 21
> > format with XML and immediately radically re-write AACR2 to be an
> > input manual for XML? As Chair of one of the standards making bodies
> > most directly affected by this rather radical suggestion, I'm curious
> > to hear whether there is a groundswell of support for this course of
> > action.
> I'm surprized at the suggestion that thinking about a successor to MARC
> implies re-writing AACR2. Since AACR2 is not in any sense an input manual
> for MARC, it mustn't be assumed to be an input manual for any successor
> format either. AACR informed much of the original logic of the MARC record
> and one can assume that AACR2 will inform much of the logic of the successor
> While I don't think that we need *urgently* to replace MARC since the
> existing corpus of records is too large to enable us to do anything with
> other than a medium- to long-term timeframe, I do believe that the
> disadvantages of continuing to use MARC are beginning to outweigh the
> advantages. We are rapidly moving to a world that puts a web browser in your
> cell phone. I believe that in this world we need son of MARC for which
> there is native support in browsers and which maps rather better onto the
> relational and object databases that bibliographic systems are migrating to.
> Otherwise the bibliographic systems this community has spent billions on
> developing, installing and supporting are likely to become museum pieces.
> While MARC originally had an intellectual elegance, 30 years of continual
> minor changes and additions, not all of which were as well thought out as
> they might be, and 30 years of grandfathering existing practice has led to a
> pretty incoherent data structure. MARC records are fiendishly difficult to
> generate from and load into a reasonably well-normalized relational
> database, because of all the exception handling that must be done. MARC
> also has fundamental problems, such as its inability to support in
> hierarchical records in any rational way.
> I am therefore in favour of an effort to start the design and specification
> of a successor format to MARC. And would love to participagte in such an
> effort. Migration will, of course, have to be an important (possibly the
> most important) consideration in the specification work.
> J. Zeeman
> CGI, Ottawa