about MARC structure : additionalauthor and illustrator
Hi guys, I'm working on MARC stuff and have a question about additionalauthors and illustrators. In Steve stuff, he use for every author/illustrator, a 700 field, with $a containing the name and $e containing the role (author or illustrator) In my UNIMARC manual, i can find : 700 : main responsability : $a as name, and $4 as title. I have no $e subtag. 701 : second responsability : same structure. How to solve the difference ? -- Paul
On Tue, Jun 18, 2002 at 03:01:38PM +0200, paul POULAIN wrote:
I'm working on MARC stuff and have a question about additionalauthors and illustrators.
In Steve stuff, he use for every author/illustrator, a 700 field, with $a containing the name and $e containing the role (author or illustrator) In my UNIMARC manual, i can find : 700 : main responsability : $a as name, and $4 as title. I have no $e subtag. 701 : second responsability : same structure.
How to solve the difference ?
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. I'm also just now learning about the fixed-field tags (00x tags). There's some good information in there that I'd like to be able to use, such as media format and language. I'm going to be thinking about how to break those out into something usable. Steve- any insight to share on the MARC flavors? Thanks. - Alan ---- Alan Millar --==> am12@bolis.com <==--
Alan Millar wrote:
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.
In fact, the MARC version is table-driven : there is 1 table making the link between each MARC field/subfield, and the corresponding old-DB field. My problem was that steve hard-coded the $e field, and that's hard to solve...
I'm also just now learning about the fixed-field tags (00x tags). There's some good information in there that I'd like to be able to use, such as media format and language. I'm going to be thinking about how to break those out into something usable.
-- Paul
participants (2)
-
Alan Millar -
paul POULAIN