[Koha-devel] Catalogue API

Tonnesen Steve tonnesen at cmsd.bc.ca
Fri May 17 09:30:03 CEST 2002


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.





More information about the Koha-devel mailing list