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 --==> am12@bolis.com <==--
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.
Hi Steve- Thanks for discussing this. I'm really not trying to pick a fight; I'm just trying to see if Koha is going in a direction that is compatible with my goals. If not, I'm happy to look elsewhere for solutions to my own personal needs. On Fri, May 17, 2002 at 09:29:31AM -0700, Tonnesen Steve wrote:
On Fri, 17 May 2002, Alan Millar wrote:
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.
Hmm, I don't see HTML templating addressing this issue at all. I'm looking at it in terms of being a programmer and wanting to operate on the data in a reasonable fashion. HTML templating does not address the issues of data normalization/denormalization and how the logic manipulates the data entities.
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.
I agree with that goal, but disagree with what "MARC compatible" means. Based on the current development branch with acqui.simple/marcimport.pl, we are already MARC compatible. Compatibility is not a yes/no question, it is a "how much" question.
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.
Ah, here we get to the meat of the issue. I think things like the MARC_nXX_subfield_table things should be used for *only* the MARC elements that are *not* represented in the KohaDB.
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.
This reminds me of "When all you have is a hammer" (or perhaps "your favorite tool is a hammer") then "everything starts to look like a nail". Storing Koha-specific data in local Marc tags, just for the sake of saying it is all Marc, seems to me to be arbitrary and inefficient.
Hope I've clarified this a bit for you.
Honestly, I'm not trying to be difficult, but no, not yet. Consider the following: select title, author, isbn, dewey from biblio, biblioitems where biblio.biblionumber=biblioitems.biblionumber How would that be done with the new "pure Marc" database? Take the earlier example: marc_1XX_subfield_table subfieldcode=1532 tagcode=658 bibcode=154 subfieldorder=1 subfieldcode=a subfieldvalue=Dolch, Edward W. valuebloblink=NULL What I'm gathering from your proposal is that the above query would be replaced with something like: select authortable.subfieldvalue as author, titletable.subfieldvalue as title, isbntable.subfieldvalue as isbn, deweytable.subfieldvalue as dewey, from marc_1XX_subfield_table as authortable, marc_2XX_subfield_table as titletable, marc_0XX_subfield_table as isbntable, marc_0XX_subfield_table as deweytable, marc_1XX_tag_table as authortagtable, marc_2XX_tag_table as titletagtable, marc_0XX_tag_table as isbntagtable, marc_0XX_tag_table as deweytagtable where authortable.tagcode=authortagtable.tagcode and authortagtable.fieldcode='100' and titletable.tagcode=titletagtable.tagcode and titletagtable.fieldcode='245' and isbntable.tagcode=isbntagtable.tagcode and isbntagtable.fieldcode='020' and deweytable.tagcode=deweytagtable.tagcode and deweytagtable.fieldcode='082' and authortable.bibcode = titletable.bibcode and authortable.bibcode = isbntable.bibcode and authortable.bibcode = deweytable.bibcode And *that* is only assembling the record set (and only 4 columns); it doesn't even include *which* records to select. I can't even begin to figure out what the real one-to-many relationships would be here. As a programmer, I cannot see this being practical for my skill set to work on. I really just want to be able to select columns from tables in a reasonable manner. I don't want to sound harsh, but frankly, if this is the goal, I'd like to know now so I can wish you good luck on it and look elsewhere for something that fits me better. Thanks for taking the time to discuss it. - Alan -- ---- Alan Millar --==> am12@bolis.com <==--
participants (2)
-
Alan Millar -
Tonnesen Steve