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 <==--