[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Koha-devel] Itemtype and MARC21 Quandry

From: Chris Cormack
Subject: Re: [Koha-devel] Itemtype and MARC21 Quandry
Date: Sun Oct 2 18:34:44 2005
User-agent: Debian Thunderbird 1.0.6 (X11/20050802)

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

How should we handle the (repeatable) 852 fields in a record when they
contain some biblioitem-level stuff and some item-level stuff (like

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 Cormack                                      Katipo Communications
Programmer                                         www.katipo.co.nz
027 4500 789

reply via email to

[Prev in Thread] Current Thread [Next in Thread]