Gday Kohaers Yea I have been using and working with Koha in a library in a remote school just outside Wewak in PNG. We have no internet connection so I have to download all the perl modules manually. I have a few thoughts and suggestions. Firstly that Koha should come with a FULL INSTALL option. I have to download each file manually off a dial up connection. So when a perl module changes and no one knows I am left with a broken system making upgrades very difficuld. Since perl modules seem to have no stability at all in relation to KOHA can I suggest that we have a Full install (ie a version of KOHA + all perl librarys that are known to work with it). Secondly My librarian is very dissapointed with the package. She really lamented not sending for payed software due to numerous bugs in Koha (namely the reports DON't work at all and seem to be tailored to a particular librarys needs). Though another bug is that when you delete a item in koha 2.25 you still have the biblioitem remain. Now this bug is very common throughout Koha as there seem to be allot of linkage tables. ie Biblio - Biblio items - Items - etc. Another good example is where does the Dewey get saved I found three different places. What I suggest that to fix problem nr 2 is that we redo the database and normalise it. Ie work out the 1 to 1 and 1 to many relationships so that they interconnect properly. If we have situations like multiple publishers, etc that we ignore these and stick with a simplified database. Why do I say that, simple Koha is just too unreliable at the moment. Please do not hit above your weight. Simplify Koha and make it reliable. Features are great but only if they work and in Koha it's about 95% of the time. my Two cents. Colin McD P.S. feel free to abuse this email in responce I probably will not be able to read the responces.
colmcd@optusnet.com.au wrote: [...]
Firstly that Koha should come with a FULL INSTALL option. [...]
This is called a Bundle and I think it will be easier with the new installer model (for 3.0), but I've not investigated it yet.
Secondly My librarian is very dissapointed with the package. She really lamented not sending for payed software due to numerous bugs in Koha (namely the reports DON't work at all and seem to be tailored to a particular librarys needs). [...]
That's not a bug, but it is a major missing feature in 2.2. I'll leave the database design questions to someone more databasey. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
I sent this some time ago but sent it from the wrong address so I don't think it arrived. Sorry if it appears twice. On Saturday 01 September 2007 03:26, colmcd@optusnet.com.au wrote:
Secondly My librarian is very dissapointed with the package. She really lamented not sending for payed software due to numerous bugs in Koha (namely the reports DON't work at all and seem to be tailored to a particular librarys needs).
This last point is, I think, common with PD software. While commercial software may be designed from the start to suit every possible customer, PD software usually is developed from a program that was written for one particular person/company/institution. Koha was designed for a particular library in New Zealand and this shows. eg C4/Search.pm contains 16 lines converting between "nz" and "new zealand" but nothing converting "uk" into "United Kingdom" or "PNG" into "Papua New Guinea". The thing that causes me problems at the moment is that the original library seems to have had a need to catalogue mainly standard fiction books and the Marc fields that it was interested in do not include many that were vital in relation to other types of book. So the biblio tables only contains a limited amount of information: CREATE TABLE biblio ( biblionumber int(11) NOT NULL default '0', author text, title text, unititle text, notes text, serial tinyint(1) default NULL, seriestitle text, copyrightdate smallint(6) default NULL, timestamp timestamp(14) NOT NULL, abstract text, PRIMARY KEY (biblionumber), KEY blbnoidx (biblionumber) ) TYPE=MyISAM; It seems that a subsequent user of Koha needed the subtitle of books. Instead of adding subtitle to the biblio table (and making huge alterations elsewhere in the code) he seems to have found it easier to add a completely separate table: CREATE TABLE bibliosubtitle ( subtitle text NOT NULL, biblionumber int(11) NOT NULL default '0', KEY bibsubidx (biblionumber) ) TYPE=MyISAM; I am a lawyer and my library consists mainly of legal text books and law reports. (Legal systems based on common law, such as England, rely extensively on law reports while they are I understand less important in systems based on civil, ie Roman, law such as France.) While a novel will only normally be published in one edition, a text book will usually go through a number of editions, each one rewriting the previous one. Lawyers often need to consult old editions to see what the law was at a particular time in the past. So "Snell on Equity" is now in its 31st edition. However if I look at eg the report of Halifax BS v Thomas http://www.bailii.org/ew/cases/EWCA/Civ/1995/21.html I will find that the Court of Appeal said: "English law has not followed other jurisdictions where the constructive trust has become a remedy for unjust enrichment. As is said in Snell's Equity 29th ed. (1990) at p.197: "In England the constructive trust has in general remained essentially a substantive institution; ownership must not be confused with obligation, nor must the relationship of debtor and creditor be converted into one of trustee and cestui que trust."" A lawyer who wants to rely on that case would naturally want to look up this passage in both the 29th and 31st editions (and possibly other editions) of Snell to see if there are any changes. So the OPAC interface needs to show the edition of the book. (And the same applies to the results of z3950 searches. If I search for the title rather than the ISBN I would like the results to show me the edition: several times I have found that I have downloaded details of the wrong edition.) The large law libraries, such as that of Lincoln's Inn or the Institute of Advanced Legal Studies will all have on their shelves all 31 editions of Snell. We probably have about four of them, on different shelves in two different buildings. I would have thought that the same requirement to know which edition of a book is available would exist in all reference and professional libraries. (And may be other users want to be able to display other pieces of information from the Marc easily on the OPAC.) However Koha does not make it easy to do this. All biblios of text books I get from z3950 searches include the edition in marc 250 (a and sometimes b) and if I edit the biblio with Marc turned on it shows up. But getting at it so that it can be displayed in the appropriate places (eg in the OPAC result of search page) seems to be extremely difficult. The only solution I can see at the moment is to go through every biblio adding the edition at the end of the title: which would be extremely boring to do. I hope that version 3 of Koha will be more flexible. But that would appear to be a long way off: is there any way of kludging things in v 2.9? Roger -- Roger Horne roger@hrothgar.co.uk http://hrothgar.co.uk/YAWS/
On 11/09/2007, at 8:38 AM, roger@hrothgar.co.uk wrote:
I sent this some time ago but sent it from the wrong address so I don't think it arrived. Sorry if it appears twice.
On Saturday 01 September 2007 03:26, colmcd@optusnet.com.au wrote:
Secondly My librarian is very dissapointed with the package. She really lamented not sending for payed software due to numerous bugs in Koha (namely the reports DON't work at all and seem to be tailored to a particular librarys needs).
This last point is, I think, common with PD software. While commercial software may be designed from the start to suit every possible customer, PD software usually is developed from a program that was written for one particular person/company/institution.
Koha was designed for a particular library in New Zealand and this shows. eg C4/Search.pm contains 16 lines converting between "nz" and "new zealand" but nothing converting "uk" into "United Kingdom" or "PNG" into "Papua New Guinea".
The thing that causes me problems at the moment is that the original library seems to have had a need to catalogue mainly standard fiction books and the Marc fields that it was interested in do not include many that were vital in relation to other types of book. So the biblio tables only contains a limited amount of information:
[Big Snip] Hi Roger Those tables are a red herring really, its the marc_subfield_data which holds the complete data. And anything in there can be shown in the OPAC. So anything in the MARC can be shown in the opac. You just have to pass it through to the template. Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131
participants (4)
-
Chris Cormack -
colmcd@optusnet.com.au -
MJ Ray -
roger@hrothgar.co.uk