Thursday, September 25, 2003 21:39-23:12 CDT Chris Cormack <chris@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