On Sat, 26 May 2001, Chris Cormack wrote:
Anyone else have anything to put on the wishlist?
How about abstracting the book information behind an API of some kind. The API needs to be generic enough to support the current Koha way of storing information, as well as MARC format type data. I haven't given this a whole lot of thought yet. As Koha works now, when you get a biblio, biblioitem, or item object, it basically contains all of the fields from the MySQL tables. MARC record data, I think, should be associated with the biblioitem objects. We need some way of referring to MARC data from that object: $biblioitem->{'marc'}->{'245'}->{'a'} = 'Tails that talk and fly'; $biblioitem->{'marc'}->{'100'}->{'a'} = 'Swanson, Diane,'; This is a little simplistic, as many fields and subfields are repeatable. Thus, the values may have to actually be arrays of values. {$biblioitem->{'marc'}->{'650'}}[1]->{'a'} Would return the 'a' subfield of the second 650 field for $biblioitem. The API should be capable of reading and writing data to the underlying database tables. Thus, the acquisition modules should be able to create a $biblioitem object and pass it to the API for insertion into the database, or the cataloguing module should be able to modify a subject entry for a biblio that is already in the database. Somebody wrote to me privately and pointed out this database schema which is quite elegant, and allows full storage of a MARC record in SQL tables: http://osdls.library.arizona.edu:4000/design.html Steve Tonnesen Coast Mountains School District Hazelton, BC, CANADA