More technical mumbo jumbo. I'm thinking the new Catalogue API should have two interfaces: one that is modelled on the biblio,biblioitems,items table and one that is modeled on the MARC data. Here are my ramblings on the first interface, which would need to be implemented first anyway. Adding a new item: Create a $item object: $item->{'biblioitemnumber'}=xxxx; $item->{'barcode'}=xxxxx; . . . dateaccessioned=xxxxx; booksellerid=xxxxxx; homebranch=xxxxxxx; price= replacementprice= replacementpricedate= notforloan= restricted= holdingbranch= itemnotes= Call Catalogue->AddItem($env, $item) The AddItem subroutine can insert the data into a new items record as before, as well as: Grab the MARC Record_ID number from the biblioitems table for biblioitemnumber given in the $item object and add an 852 tag for the new item in the MARC record. We still have to work out where in the 852 tag the different bits of information will be stored, or if some information maybe should be stored elsewhere, like in 859 (any tag, subfield, or indicator with a 9 in it is a local implementation). Catalogue->UpdateItem($env, $item) could be used to modify an existing item. The $item object in this case would also have to have an itemnumber. The MARC side could grab the barcode from the items table to find the corresponding 852 entry in the MARC record. Catalogue->AddBiblioitem($env, $biblioitem) $biblioitem->{'biblionumber'}=xxxx; volume= number= classification= itemtype= isbn= dewey= subclass= etc. Again, this would add an entry to the biblioitems table, and create a new MARC record. The Record_ID value from the newly created MARC record would also be inserted into the new biblioitems record in a new Record_ID field. Catalogue->UpdateBiblioitem($env, $biblioitem) Same idea as UpdateItem... Catalogue->AddBiblio($env, $biblio) Catalogue->UpdateBiblio($env, $biblio) These two subroutines have no counterpart in the MARC side. The data contained in the biblio table is stored in the MARC record for each of the corresponding biblioitems. All of the MARC records associated with a given biblio would have a unique id (same as the biblionumber) stored somewhere in the MARC record, location still to be determined. I'm not sure at the moment how many places in the existing Koha code will have to be modified to use this new API. All over the acquisitions code, for sure, as well as the catalogue editing code. Any other places that need looking at? Any spots in the code where updates may not fit with my proposed API here? Reading subroutines would be similar to the writing subroutines: Catalogue->GetBiblio($env, $biblionumber); Catalogue->GetBiblioitem($env, $biblioitemnumber); Catalogue->GetItem($env, $itemnumber); something like that. These three subroutines would _always_ read from the MARC record data. This will be more difficult than the current setup which just grabs the entire row from an SQL select statement and returns the result as the object, but it ensures that there is a single authoritative data source and allows for the eventual removal of the biblio, biblioitems and items tables once their functionality is completely met by the MARC records. These subroutines, specifically the GetBiblioitem and GetItem would also return some structured MARC data: 1: a full MARC record, 2: a text structured MARC record, 3: an HTML formatted MARC record. Steve.