Re: [Koha-devel] Catalogue API

[Alan Millar]

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     --==> address@hidden <==--