On Tue, Jun 18, 2002 at 03:01:38PM +0200, paul POULAIN wrote:
I expect that this will be a problem not only with illustrators, but
also with other data items we just haven't named yet.
I just borrowed a book on MARC from my local public library. It is
fairly recent, published in 1999. It talks about the idea of
"Marc format integration", which means accepting data in multiple
(or possibly all) flavors of Marc. The main idea is that some
tags should be considered obsolete, and software should be able
to accept Marc codes from multiple standards (UNIMARC, USMARC, CANMARC,
etc.). Software should accept obsolete tags/subfields as input and
map it to the appropriate place, but only produce current standard
tags on output. The book is "MARC Manual" by Deborah J. Byrne,
ISBN 1-56308-176-8.
If we are normalizing data like the current Koha DB, it is not a
problem to accept the data from multiple tags and put it in the
correct place. The software *should* be table-driven for the
tag/subfield to database mapping, not hard-coded. I did this
in Rel 1.2 acqui.simple/marcimport.pl. Take a look at %tagmap and
&extractmarcfields. I haven't looked through the 1.4 MARC handling
but I'd recommend a similar approach.
In a pure Marc mode, we need to decide how to handle variant
or obsolete items. Do we keep them in original form, or map
to new standardized locations? I'd recommend normalizing, but that's
just me. If the software is table-driven, and not hard-coded,
each site could even decide which flavor or variant of MARC it prefers.
Use this list for USMARC, this one for UNIMARC, or customize as
you like, etc.