[Koha] inconsistencies in acquisition.simple process

[baljkas at mb.sympatico.ca]

Thursday, September 25, 2003	21:39-23:12 CDT

Chris Cormack <chris at katipo.co.nz> wrote:

>> >[snip] 
>> >But I think the form has been designed in a way so that it looks
>> >like we'd need 3 biblios for the above example .. which is not >>
>right.
>> 
>> That's where you have things wrong, my friend. [snip]
>> *** Three different items do require three different records. ***
>> 
>Ahh, see this is where I think people confuse internal storage with
>external representations.

Okay, I think I see where we are getting confused.

The external representations as you termed them are what the basic
bibliographic library record MUST describe. This is the data that is coded
in a MARC system, just as it was 'coded' in the areas of old catalogue
cards.

The system of authorities (proper or authorised or used forms,
cross-references, see also's, broader terms, narrower terms, related terms)
belong to another level. Although some bibliographic records have embedded
authorities (this was noted in passing recently in follow-up to the
questions about Koha usage of 090 for call number), most systems try to
separate the two distinct functions/levels.

What is happening, in essence, Chris, is prioritizing of the authority
(what the biblio is acting as) at the expense of the bibliographic record
(what Koha terms the biblioitem). There is no simple, neat way of having
one 'master' record for different physical manifestations of the work
(again, not talking about FRBR).

I think in terms of MARC record coding, so perhaps this is more evident
from that viewpoint. Let me try an expansion of your The Lord of the Rings
example from a MARC perspective.

For each of the different physical manifestations of that work in the
collection, the regular print book, the DVD, and the large print work, you
need a separate record. There are differences, automatically, in the
following MARC coding fields:
     · 001 - representing the digital accession number, if you will
     · 005 - when exactly the object entered into the library system
	     (impossible to be the same for different items!)
     · 006 - fixed-length data field required for the DVD, because it
	     does come with accompanying text materials (not needed for
	     the books)
     · 007 - fixed-length data field required for the DVD, but not for
	     the books
     · 008 - fixed-length data field required for all 3, but the coding
	     in each is different, e.g.

		  with 9=any number, #=blank and L=any letter
   'regular' book  008 999999s9999####LLL####g######000#1#eng#d
 Large Print book  008 999999s9999####LLL####gd#####000#1#eng#d
	      DVD  008 999999s2009####LLL999#g|||||#####vceng#d
	     Admittedly, these are close, but they are not identical

     · 010 - different for the books and possibly nonexistant for DVD
     · 020 - (ISBN) same as with 010
     · call number - almost certainly different for all 3 since few
       libraries shelve multiple formats together.

     · 100 - MAIN ENTRY 
	     The fun really begins with this core field, though.
	     The DVD, as much as we all love Tolkien, would not have him
	     as the author in 100 because, by definition, the film is a
	     work with shared responsibilities. LC has a relevant	   
	 exemplum in the record for the first movie, which removes
	     Tolkien from the 100 (although I'd question the absence of
	     a 700 for him and for the director).

     · 245 - The title and statement of responsibility would have a
	     different [GMD] h subfield for each form of the item, i.e.

  'regular' book  245 14 $aThe lord of the rings :$h[text]
						    |--- usually omitted
Large Print book  245 14 $aThe lord of the rings :$h[text (large print)]
	     DVD  245 04 $aThe lord of the rings :$h[DVD videorecording] 

     . 250 - would record different editions for the text
     · 260 - would have different publishing information for all
     · 300 - would show different physical details for each item, e.g.
  'regular' book  300 ## $a299 p. ; 18 cm.
Large Print book  300 ## $a699 p. ; 28 cm.
	     DVD  300 ## $a1 videodisc (ca. 3 hours) :$bsd., col. ;
			 $c12 in. +$e1 booklet.

There is a reason that the library card catalogue and MARC after it are
item-based. In a traditional system, card or online, the title alone would
act to gather these three different entities together. (Each of their
records (in some way) would indicate the number of copies held.)

So, I guess, I would have to ask, how in the world does the biblio level
store ALL that data, with all the differences, and then parse it into the 3
distinct entries for the 3 different types of items?

That seems to me more complex than the repetition that might exist. In
fact, for your example, the only part that I can see as repeating, would be
title parts of the 245 (depending on who coded them, a and b and/or p
subfields) and maybe a 520 summary. Otherwise, the rest of the data would
be different. (It is not correct, BTW, to code properly for one entity
(say, the first in the collection) and then base other items off of that
when they differ.)

I don't understand the rationale for the biblio level unless it is acting
as an attempt at an authority. From a MARC-perspective, the utility of the
biblio level is confusing. I would still rather see a fully developed
authority system (although I realise that it is ridiculously simple to
express one's druthers especially when one has no idea how to program a
system to do it or how complex such a task is).

Chris, I hope that this is not just frustrating to you. But I really don't
see what the biblio level is trying to do or how it simplifies storage at
all.

>If I can export records in a format like that, [etc. snip]

Like what? Really, I don't know what you mean.

>What I was talking about is how Koha stores the data .. I think if its
>possible to create valid catalog records that correspond with
>standards, then how we store the data internally doesnt matter.

Certainly, but I don't understand how it's being stored in this way nor how
parsing out the proper information is in any way 'easier' than having it
based on the biblioitem level, say.

>Apart from the obvious storing it in a way that provides for fast
>access. And minimal redundancy.

Redundancy is avoided by checking for items already in the collection.
Strictly speaking, a new record is required by each different manifestation
of the work (although this is sometimes ignored in practice). For example,
in the military library where I last worked as a cataloguer, we had 5
different editions of a work by Cajus Bekker on the Luftwaffe: following
the rules strictly, we had 5 different records, with 2 copies each of the
2nd and 5th noted in the holdings (ironically also in a 090 field subfields
c and p, in the system we were using).

>Perhaps I didnt make that clear enough in my message :) I was talking
>about the internal structure.	

Maybe you could point me and others in the right direction to see how the
internal structure is working to do this. I really don't get it.

Thanks again, Chris,

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