[Koha-devel] Catalogue API

[Alan Millar]

I'd like to help a little in development or code clean-up.  But, wow, it
looks like it's going to be a full time job just keeping track of the 
mailing list(s), Wiki, and IRC logs...   

I'd like to throw in my opinion on some development directions, but
I can't figure out where I should be doing it, so I guess I'll do
it here :-)

This is all hobby for me; I have about 1500 books in my personal
collection that I want to catalog.  I don't have the same issues that
"real" libraries have.   In that context, I really like MARC compatibility
so I can snarf data from elsewhere to avoid data entry, but I don't
want to eat/sleep/breath MARC records as my way of working on the data.  
Yes, I understand that some librarians do want that.

The library patron will never want to see MARC data, so if for no
other reason than that there will always need to be an abstraction
of the data, such as making bibliographic data separate from individual
item copy data.  I think that the current three-tier structure of
biblio, biblioitems, and items is actually a very good one.

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.

As long as updates are done through the API, the kohadb could go away
(although I'm not convinced that is a good idea, and if updates are
done through the API it wouldn't need to) but the data model should not
go away.

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?

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.

As a non-library person, I may be all wrong here, but thanks
for letting me share my thoughts.

- Alan

-- 

----
Alan Millar     --==> address@hidden <==--