[Koha-devel] Itemtype and MARC21 Quandry

[Chris Cormack]

Joshua Ferraro wrote:
> On Sat, Oct 01, 2005 at 08:57:37AM +1200, Chris Cormack wrote:
> 
>>If you have a MARC record that contains multiple record types, you 
>>should get 1 biblio -> multiple biblioitems -> multiple items.
>>
> 
> I think this is how UNIMARC is handled, but not MARC21. When bulkimporting
> MARC21 records, there is 1 biblio, 1 biblioitem, multiple items (and
> the biblio number and biblioitemnumber are the same for the initial
> import).
> 
> How should we handle the (repeatable) 852 fields in a record when they
> contain some biblioitem-level stuff and some item-level stuff (like
> barcode).
> 
> While we're on the topic:
> Chris's original db design (biblio->biblioitem->item) comes very close
> to the (fairly) new Functional Requiremente for Bibliographic Records
> (FRBR) (http://www.oclc.org/research/projects/frbr/default.htm). Looking
> forward, are we aiming to come closer to FRBR or are we going to stick
> with the original design and fix MARC21 support to use that design?
> Any opinions?
> 
It depends entirely what we are planning for Koha 3.0.
Im not sure I see the point in changing the database to be closer to 
FRBR if we are going to be using MARC records in the background.

IE if we are planning to have our new textual db, in Zebra, with all the 
bibliographical data in it, and just the item status stuff. (Plus all 
the borrowers, circ, accounts etc) in the relational db, then I dont see 
much point.
If we do it that way, its all just interface, we can provide whatever 
interface we want for the cataloguers, as long as the data is stored ok.

The way we store something, is not the way we have to display it, thats 
what my entire bone of contention with MARC is, people have confused a 
storage and exchange standard, with a interface standard. But thats a 
whole other rant. :)

In my opinion, we should be looking for a storage structure, that allows 
for robust and fast access. And I think zebra will do this for our 
catalogue data, and i think the relational db willl do it for our more 
time critical (issues etc) data.

As long as we can put people like Brookes mind at rest, that changing 
the underlying structure wont bust the way koha works, just make it 
faster/better. Then I think we are all good.

Chris
-- 
Chris Cormack                                      Katipo Communications
Programmer                                         www.katipo.co.nz
027 4500 789