January 2003 - Koha-devel - lists.koha-community.org

Re: [Koha] some thoughts about cataloguing and acquisition (important)
by paul POULAIN 17 Jan '03

17 Jan '03

I think i must explain some things about 2.0 version... The Database exists in 2 forms : * "standard db" : the DB coming from the 1.2 version * "MARC-DB" : the MARC one. A parameter tables maps marc fields and standard-db ones. The new 2.0 guarantees that both DB are always synchronised. That's why it was long to write, and to debug. But, now we have a big advantage, as the user can decide to use MARC or non-MARC interface. In both cases, the 2 databases are living. If you choose the MARC one, the parameter tables provides the following features : * support any MARC flavour : just define what 100$a, 200$a... mean * support what you want in your MARC flavour : 100$a => used 100$b => used, but less important, 100$c => ignored The manual MARC cataloguing tool is ready in 1.3.3, and used by a french library in France. My question was not about marc/non marc, my question was to have advices for a deepest separation between acquisition and cataloguing. I repeat that here, in France, there are almost no librarians that enters manually their biblios : universities have a common pool, the National Library (BNF) provides a cdrom with 4 millions of UNIMARC notices, and Electre provide a commercial one with recent books. So most ils separate acquisition and cataloguing, as librarians "spend not more than 10 mn a week on cataloguing" as mailed me a french koha-addict ! Let's continue your answers/ideas/... on this topic, i'll conclude and propose something (on the wiki) next week. you'll be informed of my proposal when ready, and get the opportunity to comment it too ! Note : i plan to do something SIMPLE (from a developping time point of vue) for the 2.0 release which should occur in a month (at least for a RC one) In 2.0.1, I expect to improve it (i WILL improve it if it's funded by someone !) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: some thoughts about cataloguing and acquisitions [important]
by Stephen Hedges 16 Jan '03

16 Jan '03

Hi, Paul, and thanks for opening an interesting topic - I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. My thoughts are based on my experience with library users and librarians. We have found that library users appreciate the ability to make purchase suggestions and see what the library has on order, even place reservations on items before they arrive at the library. In other words, a good acquisitions system allows users to see not only what the library has, but what the library WILL have, and also gives them the power to suggest and reserve things the library has not ordered. That means the acquisition system needs to deal in records that are nearly complete, so people can search for items by title, author, ISBN, subject, etc. Cataloguing, in that case, merely adds the "labeling" to the item once it arrives, i.e. barcodes, spine labels, etc. The item has already been cataloged in all other respects as soon as it is ordered. As for librarians, I had a conversation with the tech guy from Worthington Public Library who suggested that they might be willing to put money toward a really good Koha acquisitions system, one that would allow the librarian to automatically search for an item and compare prices from several different vendors and download any MARC records available from vendors with a minimum of effort on the part of the librarian. He had other thoughts, as well, because he had been wrestling with searching for a good acquisitions system for some time, but I unfortunately can't remember them now. Both of these experiences lead me to believe that any ILS that wants to be competitive in the future should pay close attention to its acquisitions component. I think both library users and librarians are going to demand much more functionality than what is currently available in most ILS acquisitions systems. Stephen H. > I want here share some ideas for the 2.0 version > of koha, around > cataloguing and acquisition. > > Most ILS, in France at least, separate > cataloguing and acquisition. > * *cataloguing* is often done through a CDROM > (from the BNF for example) > : the librarian download from the cd the biblio > in MARC format, which is > included in it's ILS. The cataloguing refers only > to BIBLIO notice, not > items and how they arrive in the library. > * *acquisition* referers to how "books" arrive in > the library (and > includes items) > > In koha, at the moment, there is no distinction > between those 2 topics : > look at koha main page, there is only a > "acquisition" picture, which > includes cataloguing and acquisition in fact. > I want to begin de debate to see if it's a good > idea to distinct > acquisition and cataloguing in 2.0. > It would mean : > * in mainpage => 2 links for cataloguing and > acquisition > * acquisition => works almost like the normal > acquisition system of the > old version : search for a supplier, enter a > little part of the biblio... > * cataloguing => > - if marc is selected : works like the > acqui.simple in 1.3.3 (see > demo.koha-fr.org) > - if marc is not selected : works like the 2nd > part of the normal > acquisition in 1.2 : enter the biblio details. > this supposes a new parameter in the > systempreferences table. > > One other idea : it would enable a "suggestion" > feature in the opac : > readers could suggest books to add, which could > be stored in the > "acquisition" part of koha, in a "to validate" > status. > > From a developper point of vue, this means : > * duplicating biblio table to acqui_biblio table > * split normal acquisition in 2 parts > * change normal acquisition to write acqui_biblio > table and not biblio > * create some screens to link the acquisition > part and the cataloguing one. > some work, but not too much i think (if someone > wants to fund it, send > me a mail :-) ). > > Of course, if you create a book in the > acquisition part, all what you > typed would be auto-copied when entering the > cataloguing part :-) > So there should not be too much more work for the > librarian/cataloguer > (but a few, anyway : this would add screens, so, > more clics) > > -- > Paul POULAIN > Consultant indépendant en logiciels libres > responsable francophone de koha (SIGB libre > http://www.koha-fr.org) > >

1 0

new The Perl Review
by Pat Eyler 16 Jan '03

16 Jan '03

Hello all, just another reference to point out to people, the new 'The Perl Review' is out and contains an article called 'Separating code, presentation, and configuration' by brian d foy see http://www.theperlreview.com/ Since this kind of modularization has been coming up on the list (and will be one of the major goals of 2.1/2.2), I thought it worth sharing. On a similar not, brian has asked (in his use.perl blog) for people to write articles about applications written in Perl. Is anyone interested in writing something about Koha for the TPR? thanks, -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0

Koha version 1.2.3rc26 released
by Chris Cormack 16 Jan '03

16 Jan '03

Release Name: 1.2.3RC26 (adds templating and authentication)n Notes: This should be the final release candidate for the 1.2.3 version of Koha. RC26 provides a few bugfixes and some new patron access features (like patron reserve setting) This is a release candidate. It is not intended for production systems Changes: Changes: * Templating of all of OPAC * Authentication system added. Authentication will be mandatory for all access to intranet system, and optional for OPAC (gives access to account information ability to request/renew items). * Added user flag systems to set access to individual parts of the intranet. Sample data allows "librarian" user to have full access, but jdoe and jsmith users have no access to members pages * Fixed problem in RC2 where Database.pm and Koha.pm depended on each other. * Fix to Auth.pm that broke basic authentication feature * Fix to updatedatabase fixes problem with full acquisitions * Can search for ' ' (space) to return entire holdings (bug in search templates fixed) * modularized installer.pl * Z39.50 client startup scripts now read /etc/koha.conf for directory locations. * Added copyright and copying permission statements to all scripts and modules to qualify for submission to FSF's savannah system * Added fixes to branch transfers and reserves * Fix for editing access flags from borrower's editing page * Fixed search navigation buttons (numbers in square boxes on search results pages) * Fixed printer.pl printer administration script * More intranet scripts protected by checkauth cookie based authentication This is still not completed! Use Basic Auth if you need authentication for now * Fixed bug in subject search results page (top navigation bar was duplicated at the bottom) * Fixed bug in moditem.pl (was showing the wrong biblio information) * Katipo's opac authentication work * Some bugfixes to the installer script that fix bugs introduced in RC15 * Fixes to branch admin script. Multiple branches will now work in circulation module as expected. * Fixes to branch selection code in circulation module when there is only one branch. * Fixed broken subject searches * New admin script for Z39.50 server list * bulkmarcimport.pl and updatedatabase can now be run without having to set the path to the Koha modules directory * New Memeber entry now respects a date format option in system preferences (mm/dd/yy vs dd/mm/yy) * Fix form for Z39.50 server admin page * Merged some scripts with trunk in CVS * bulkmarcimport.pl script moved to INTRANETDIR/scripts directory * Test::Harness test scripts installed in INTRANETDIR/scripts directory (testKoha.pl) * Custom templates are now left alone in INTRANETDIR/htdocs and OPACDIR/htdocs * Fixed dangling biblioitem bug (deleting a biblio with existing biblioitems was leaving the biblioitems behind) * patrons can now set their own reserve requests from the OPAC interface. Enjoy ... bugs to bugs.koha.org :-) Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz

1 0

some thoughts about cataloguing and acquisitions [important]
by paul POULAIN 16 Jan '03

16 Jan '03

I want here share some ideas for the 2.0 version of koha, around cataloguing and acquisition. Most ILS, in France at least, separate cataloguing and acquisition. * *cataloguing* is often done through a CDROM (from the BNF for example) : the librarian download from the cd the biblio in MARC format, which is included in it's ILS. The cataloguing refers only to BIBLIO notice, not items and how they arrive in the library. * *acquisition* referers to how "books" arrive in the library (and includes items) In koha, at the moment, there is no distinction between those 2 topics : look at koha main page, there is only a "acquisition" picture, which includes cataloguing and acquisition in fact. I want to begin de debate to see if it's a good idea to distinct acquisition and cataloguing in 2.0. It would mean : * in mainpage => 2 links for cataloguing and acquisition * acquisition => works almost like the normal acquisition system of the old version : search for a supplier, enter a little part of the biblio... * cataloguing => - if marc is selected : works like the acqui.simple in 1.3.3 (see demo.koha-fr.org) - if marc is not selected : works like the 2nd part of the normal acquisition in 1.2 : enter the biblio details. this supposes a new parameter in the systempreferences table. One other idea : it would enable a "suggestion" feature in the opac : readers could suggest books to add, which could be stored in the "acquisition" part of koha, in a "to validate" status. From a developper point of vue, this means : * duplicating biblio table to acqui_biblio table * split normal acquisition in 2 parts * change normal acquisition to write acqui_biblio table and not biblio * create some screens to link the acquisition part and the cataloguing one. some work, but not too much i think (if someone wants to fund it, send me a mail :-) ). Of course, if you create a book in the acquisition part, all what you typed would be auto-copied when entering the cataloguing part :-) So there should not be too much more work for the librarian/cataloguer (but a few, anyway : this would add screens, so, more clics) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

MySQL and foreign keys
by Larry Currie 15 Jan '03

15 Jan '03

Last night I attended a PerlMongers group meeting here in Oakland, CA and one of the presenters at the meeting asserted that MySQL could not claim to be a completely relational database because it doesn't let you define foreign keys. As a result, he feels that MySQL fails the ACID test (atomicity, consistency, referential integrity, and durability), and he advised people to avoid using it in Perl applications and instead use Postgres or some other relational database with more stability. He cited an example where you might have a one-to-one relationship between primary key values in two tables and if you deleted a value from one of the tables, MySQL would leave that value in the other table as dangling data without warning you to take care of it and as a result really mess up your database. Can anyone on the Koha list comment on this assertion and what the consequences might be for Koha? Larry Currie -- Lawrence W. Currie User Services Librarian California Academy of Sciences Golden Gate Park San Francisco, CA 94118 lcurrie(a)calacademy.org (415) 750-7108 (415) 750-7106 fax http://www.calacademy.org/research/library/

2 1

Re: [Koha-devel] 1.2.3RC26 Install.pm
by Bobby Billingsley 15 Jan '03

15 Jan '03

Hi people ... I've just had a go at upgrading from 1.2.2 to 1.2.3rc26 and ran into a snag w. the "koha.upgrade" - the code to figure out where mysqladmin lives doesn't seem to check enough locations. Adding /usr/local to the list helped (on my FreeBSD installation). I guess the same goes for the "Install.pm" script, so her are a couple of patches for your perusal :-) /bobby -- -- -- -- -- -- -- Bobby Billingsley, General Specialist -- -- -- -- -- -- -- ___ .--.- \ | | _ `-,_`--'__/ x./_ | Remember to love while you dare | ASCII ribbon campaign ( ) //-_`--/ //\ \ | remember to live while you do | - against HTML email X \__/ `---' \__/ | -- Piet Hein | & vcards / \ Lat: 55° 40' 52" N Lon: 12° 32' 56" E Anyone without a sense of humor is at the mercy of the rest of us :->

1 0

[Bug 116] found items counted wrong
by bugzilla-daemon＠wilbur.katipo.co.nz 15 Jan '03

15 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=116 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version| |All ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2003-01-16 10:50 ------- Fixing this will require some extensize rewriting of the search module so I'm going to put it off for the 2.0 series. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 120] subject search with apostrophe in it (ie NISGA'A) does not work.
by bugzilla-daemon＠wilbur.katipo.co.nz 15 Jan '03

15 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=120 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2003-01-16 10:39 ------- Fixed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 127] Can't delete dangling biblio item
by bugzilla-daemon＠wilbur.katipo.co.nz 15 Jan '03

15 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=127 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2003-01-16 10:38 ------- Fixed. Deleting a biblio that has biblioitems pops up a warning that biblioitems exist and asking form confirmation to delete the biblio and all of its biblioitems. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0