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

[Andrés Tarallo]

As I've told our main concern is thinking in the futore, were we might 
be interested in exporting MARC records. Our current catalog isn't in 
MARC so we thought that an automatic aproach could be usefull, at least 
for most relevant fields.

Our two branches have more that 20.000 titles (and growing) right know 
we don't find suitable filling such database 008 fields.


Andres


Steven F. Baljkas wrote:

>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.
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20041025/483678b7/attachment.htm