[Koha] Marc Field 008? Plug-in would not work

[Steven F. Baljkas]

Monday, October 25, 2004    17:23 CDT

Hi, Paul, Andres, et al.,

I meant to get back to this right away but forgot. Sorry.

As a synopsis: Andres had been asking about whether Koha uses the 008 (at
present, no) and how to code it (automatically or manually, as required by
AACR2R and MARC21 rules).

From: "Paul POULAIN" <paul.poulain at free.fr>
To: "Baljkas Family" <baljkas at mts.net>
Cc: "Andres Tarallo" <tarallo at ort.edu.uy>; <koha at lists.katipo.co.nz>
Sent: Wednesday, October 20, 2004 2:34 AM
Subject: Re: [Koha] Marc Field 008?


> Baljkas Family a écrit :
>
> >>We have a doubt about field 008: Does Koha uses it?
> >> How is [it] filled?
> >>
> >When I last asked about this recently, I was told that Koha doesn't use
the 008.
> >
> >I am not sure how it would be filled automatically, or even if that is
what Koha tries to do with it. Otherwise, I think you'd have to create a
coding sequence that would suffice for your library's needs and meet at
least the minimum requirements (008 positions 6, 7-10, 11-14, 15-17, 35-37,
38 and 39).
> >
> >Properly, a cataloguer should be coding the 008 field *individually for
each MARC record*, since the elements that constitute the 008 can only be
coded accurately from inspection of the item being described.
> >
> >
> Another possibility [exists], implying some coding that could be added to
> official Koha : develop a plugin to do it automatically.

The problem is, Paul, that the 008 codes information NOT recorded in other
fields. As far as I can tell from my reading of UNIMARC (cf. 1xx fields),
this is as true for UNIMARC as it is for MARC21 (or CANMARC, USMARC, and
other precursors). There is simply no way that it could be derived properly
from other fields because all the information it is supposed to code is not
coded elsewhere in any given record.

If Koha is going to claim that it follows established library standards, it
is important to realise what those standards entail.

> ESMP in France has developped plugins for 1xx fields, that also have
> many calculated bytes. Feel free to copy them (it's in value_builder
> directory of Koha) and modify for 008.

I don't know how sophisticated the plugin the Ecole Superieur des Mines
(ESMP, n'est-ce pas?) developed is, but even to try to code the 008 from
other data elements present, you would need to read from several fields,
which may or may not be there -- there might be a 041 from which one could
compile the 008 positions 35-37 for language, but 041 is often omitted;
there could be mention of all significant types of illustrative matter in
the 300 $b, but often one sees only the standard 'ill.'; there could be
various 5xx notes indicating whether an item consitutes a government
publication (and even which kind) or conference proceedings or a
festschrift, or one could even scan the 245 $b and $c to check for common
governmental department names or words/phrases indicating a conference or
festschrift -- but even if all that could be done (and it seems to me as a
non-programmer like more of a headache that just doing it properly from the
library science perspective in the first place) when all that was done,
there would still be information missing that is required according to the
minimum standards for valid records as specified in MARC21 protocols (e.g.
for books: illustrative materials, nature of contents, indexing, record
status, source, and more).

Now, as I suggested to Andres, you could code for parts of the 008 by
deciding arbitrarily that the majority of the materials have certain
characteristics, e.g., have no illustrations, are for various audiences, are
not indexed, are not government publications, not conference proceedings and
not festschriften, are not fiction, are written in English (or French, or
Spanish, whatever your dominant language is), etc., etc., creating a dummy
008. Such a dummy string might look something like this:

008 041025n########nyu###########000|0#eng#u

This is, however, not good practice, but it could be used as a stop-gap
measure. Ideally, one's records should have this information already, one
should download records with it, or have one's cataloguers spend the time to
code the records individually.

If it is still unclear to UNIMARC users why this would be so, please review
all the fields of your 1xx block: then remember that the 008 codes for
elements from almost ALL of these in one field, the position values of which
change depending on what kind of material one is cataloguing.

> The 210 and 215 plugins may also be useful to see how to find a value in
> the MARC editor (and thus automatically suggest something) : the 210
> searches for the ISBN, that is in 010 field. The 215 searches for ISBN
> (010) and editor (210) to build the list of possible collections.

I am sorry, Paul, but I just don't understand how this would work to
determine coding values for the 008.

The ISBN (010 in UNIMARC, 020 in MARC21) itself contains encoded information
for publisher (editor means something different in English) but even it
creates problems: its is supposed to be international and the numbers are
supposed to be unique, but errors do occur (I have seen 2 so far in my
career). It seems to me that a plugin for the 008 would have to be absurdly
complex in order to determine things that cataloguers do easily by sight.

Anyway, that's all I had to say on the 008 and its complexities.

Steven F. Baljkas
library tech at large
Koha neophyte
Winnipeg, MB, Canada


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.777 / Virus Database: 524 - Release Date: 14/10/2004