On Fri, 17 May 2002, Alan Millar wrote:
There are some comments on the Wiki about the Catalogue API saying that the kohadb functions would eventually go away when the Marc stuff is done. That looks like a bad move to me. I think the functions should definitely stay abstracted at the level of add/update/delete bilbio information and add/update/delete item copy information.
The user interface does not have to look anything like MARC at all. Some librarians will want to see and edit marc data directly, many will not, very few patrons would have a clue what they were looking at. The HTML::Template work is intended to deal with exactly this issue. We can have 10 different templates for viewing bibliographic data about a book. One for a simple MARC layout, one for a full MARC layout, one for librarians, one for OPAC, one for children, one for small children, etc. We just want to switch to storing the data in a MARC compatible format to ease interchanging data with other libraries that are not using Koha. Think interlibrary loans, for example. It will also allow librarians to store information that cannot currently be stored in the kohadb without modifying the database and the programming. MARC doesn't make the distinction between biblio and biblioitems the way the kohadb does, although I intend to use local MARC tags to continue to make this distinction within Koha. MARC _does_ allow multiple items to share the same MARC record though.
I'd like to see (and want to help) Koha extend to have some smoother handling for other item types, such as music CD's or videos, including using EAN/UPC codes like how ISBN's are used for books. Would the pure MARC version handle this equally well?
I guarantee you that the MARC format has the capability to store this information. It is very comprehensive.
Also, I've read a little on the Lib of Congress discussions for XML representation of MARC data. It seems short-sighted to me to tie the database too closely to the text-only view of MARC, down to the $ subfield delimiters. I'm not at all suggesting putting XML in the Koha database; rather arguing for a higher-level abstraction that can represent the MARC data without being too file-format specific.
We will not be storing data in either MARC or XML format. The data will be stored in an SQL backend (MySQL at the moment). The data will just be stored in the SQL backend in such a way that MARC or MARC-XML data can be imported/exported easily. Hope I've clarified this a bit for you. Steve.