IRC log for #koha, 2005-10-12

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
20:25 thd kados: are you around?
21:13 kados thd: I'm around now ... just not answering my phone ;-)
21:14 russ request for questions?
21:14 doh
21:14 quotation
21:14 kados right ;-)
21:14 russ time for another coffee
21:30 thd kados: look at http://www.kohadocs.org/holdings.html#d0e445 .  I have been revising the mappings part of earlier sections of this document this weekend with the addition of recommended table changes, settings usage, coverage of 942, 856, etc.
21:34 kados: I had not intended to put more detail into the cited standards description at this time.  There is a small error in the MARC 21 standards description that derived form some poor wording in LC documentation but that should not adversely affect understanding.
21:39 russ, chris: how much support for serials holdings does your prospective serials customer have already, need, expect?
21:42 russ thd: what do you mean by support? we are at the building a requirements document phase
21:42 so very early on in this project
21:43 thd russ: requirements for Koha is exactly what I mean.
21:49 kados I think what's happened in Koha development thusfar
21:50 is that we've only done the bare minimum to address the needs of a specific client
21:50 without stepping back and looking to the future in terms of what needs to happen for bigger clients down the road
21:50 actually, i think that's a probably a fair characterization of a lot of open source software
21:50 chris i think thats true, if you add in "In some cases"
21:51 kados yes ... MARC support being one of those cases ;-)
21:51 but I agree it doesn't apply in other areas where we're actually leading the pack
21:51 like interface design for instance
21:51 and use of templates
21:51 etc.
21:51 rach there is going to be a tension when a specific client is asking/paying for something
21:51 thd russ: Is the serials holdings form as it currently exists significantly insufficient for your non-MARC client?
21:51 rach it is really hard then as we all know to not get
21:52 "captured" by what that client wants
21:52 kados unfortunately, the problem with having weak MARC support (like we have now) is that we'll never really land a solid client
21:52 unless
21:52 rach The serials yes is insufficient
21:52 and inexplicable as well to a large degree
21:52 kados they _buy_ into the whole open-source 'build it to meet your needs' idea
21:52 which is a _very_ hard sell at the large-library level
21:53 chris yep, marc support is due to be fixed though isnt it, most of the problem goes away with the use of flat files and zebra
21:54 then its all interface, which is easy
21:54 correct me if im wrong
21:55 but the problem with current marc support is in the storage of it, the structure isnt flexible enough to handle the madness that is a marc record
21:55 if we just store them as marc records, this problem largely goes away
21:55 kados phone ... sorry :-/
21:55 chris and our problem becomes, showing the information to ppl
21:55 thd rach: If you want really inexplicable serials look at some of the more complex parts of captions and patterns, and enumeration and chronology fields for MARC holdings.
21:56 chris thd: the main insufficiency is, serials doesnt create items currently
21:56 so for public libraries, which issue serials
21:56 its wholly insufficient
21:56 rach so the work that paul has done, doesn't replace our original serials workaround
21:57 chris it would be fine for a library that has serials that are purely for reading within the library
21:57 but if you want to issue them, then yes, the original workaround
21:57 rach which presumably whoever got paul to do the work did
21:57 chris probably an academic library
21:57 rach yep
21:58 chris theres no reason it cant be extended to create items
21:58 rach yep which I'm hoping is where we are going :-)
21:59 chris and using a system preference variable, should be able to work for both library types
21:59 rach well at least we agree chris :-)
21:59 thd chris: There is a problem with creating very many repeating issue fields in a single MARC record.
21:59 rach within KOha, or in general?
22:01 chris repeating fields within flat file representation are always problematic
22:01 its just one of the many things wrong with MAR
22:01 C
22:01 thd rach: In MARC, the record can grow so large that MARC::PM can no longer manage it after it breaks the maximum size for a single record using repeated fields for every issue.
22:01 chris but before i start ranting im gonna go do some work instead
22:02 rach so within Koha - which is what chris has just said is looking to be quite radically changed
22:02 well it's what I understood by what he said to Kados a few minutes ago
22:02 YMMV
22:03 thd rach: The workaround is to create multiple linked holdings records before the size becomes too large.
22:03 rach: YMMV?
22:03 rach your millage may vary
22:04 - umm seems to mean you may have a different experience/understanding
22:05 are you suggesting that as a workaround, or is that what Joshua et al are implementing?
22:05 thd rach: I have not learnt most of the abbreviated IRC communications conventions yet. :)
22:06 rach ah it's a mailing list one I think - well that's where I will have got it from :-) It's quite a useful one
22:06 along with IANAL and IANAP
22:06 I am not a lawyer, I am not a programmer  - usually followed by a "but"
22:07 thd rach: Those are more common.  I learnt those a few years ago :)
22:09 rach: I have probably[D[D[a[C[C[C deciphered YMMV before when preceded by a 'but'.
22:11 rach: Multiple linked records was a suggestion.  I have not answered on the list yet to the recent question about serials.
22:17 rach: Maybe, if every issue was a linked record it could work around the field and subfield ordering problem that exists in MARC Koha currently.  Otherwise MARC serials work cannot be started until 3.0 has fixed field and subfield ordering and subfield repeatability.
22:19 chris well it wont be done before 3.0 anyway
22:19 there are no more features planned for 2.2.x
22:19 it would be kinda pointless to do marc serials then completely change the way koha handles marc
22:20 rach well yes it would
22:23 our (Katipo's) strength is not MARC - I suspect that our best contribution is in working out from the users perspectives what is wanted - so that's what we're concentrating on
22:30 thd rach: The confusing part of the serials patterns that is there now in Koha is the same as would be for MARC serials.  A friendly interface is needed for controlling the coded information that uses drop down value lists for creating the publication pattern and automatically creates an item for attaching a barcode when an issue is received.
22:34 rach it does seem to be quite a minefield
22:38 thd rach: I told kados that the full work that could be involved for adding MARC holdings standards support is comparable to the work for adding MARC bibliographic standards support to date, although, something significantly short of that could be functional at a minimal level and more affordable :)
22:40 rach: minefields just need to be well mapped so that you can walk around them until you can afford to clear them completely :)
22:44 rach the way that "stuff" has been added to Koha in the past is in a "staged" way - so first up someone does the proof of concept - then other libraries see enough to comit to doing the next stage
22:45 we are unlikely without someone dieing and leaving the project a fortune to be able to do it any other way - which for the idealists among us I susepct is pretty frustrating
22:45 chris if we did it any other way, we still wouldnt have a koha
22:45 we'd still be speccing it
22:46 rach we'd be Avanti :-)
22:48 rosa and we'd be desperate
22:49 thd rach: Except that you would have had the prudence to not start an implementation of an OSS library system in Java without enough supporting modules to make it work.
22:49 rach well yes
22:50 but the point being that our more pragmatic development style has got us a library system that libraries can acutally use :-)
22:50 but we're unlikely to be able to do the "complete soloution" to any one problem using this model, it will be a process of continued gradual improvement
22:50 as various itches are scratched
22:58 thd rach: It is difficult to find libraries in the US sufficiently satisfied with the current level of MARC support that they are even willing to invest in an incremental improvement.  I expect that will change modestly with 3.0.   I just wish 3.0 were the starting point already.
23:00 rach patience is a virtue :-)
23:04 chris its just a shame there arent more libraries are brave as hlt and npl
23:04 thd rach: eating may not be a virtue, but it is a necessary condition for filling the patience virtue
23:08 chris: It is unusual in the world generally, for a customer to pay for something that does not exist yet.
23:08 chris not really
23:08 99% of our work is doing just that
23:09 rach surely that's what all library vendors seem to do
23:09 it's a v common way to do software development
23:09 chris its what you do with a builder or an electrician or a plumber
23:09 they quote, and then they do the work, and you pay them for it
23:09 rach they don't pay for it until it's proven/done, but certainly you undertake to do it
23:09 and often pay a deposit
23:10 chris i paid for my lounge suite before it existed
23:12 and there is nothing unusual at all about commiting to pay for something when it does exist
23:12 it happens all the time
23:13 just maybe not in libraries
23:13 thd chris, rach: The difference is that to win those contracts you have to persuade the customer that you have done something sufficiently comparable.  While Koha without some major set of features seldom seems comparable to the alternatives with large license fees.
23:16 rach and this would be why when we wrote Koha we didn't chuck in the day jobs
23:16 it's a long slow haul to prove yourselves etc
23:16 our competitors have been around for a long time
23:17 thd chris rach:  you hire a house builder after seeing other houses the builder has done.  Most libraries think of Koha as just the roof perhaps and are afraid to hire roofers to build the walls and foundation.
23:20 chris ah well, we were lucky to find a few not that shortsighted and can only hope as koha improves more, it will be a nicer target
23:23 thd rach: I think the proprietary companies that still exist started with much more complete systems relative to the maturity of the market with one exception.
23:25 rach: I can think of a major proprietary systems vendor that may have started with support services at which they excelled long ago.
23:27 rach: I am supposing that if one module were able to compete with the best comparable module from any other system that Koha would be better noticed.
23:28 chris thats entirely subjective, but id put up a well skinned koha opac against any of the proprietary systems web opacs
23:29 thd rach: The task of making the whole system comparable with systems that have been around for decades is too large.
23:30 chis: It is difficult to separate the OPAC from the rest of the system.
23:32 rach From what we've seen of other systems, just making it look nicer would be a big leap forward
23:32 over other systems
23:33 chris yep, thats why i said well skinned
23:33 thd chris: Although if it could be separated, anything that can be separated and interoperable with another system would be a good candidate for using as a means for other libraries to become familiar with Koha without a full commitment.
23:33 rach people are very swayed by what things look like - if we wanted to get more credible the easiest/cheapest way would be to make it more beautifuly IMO
23:35 kados rach: I agree that that works for smaller libraries but based on the conversations I've had with some of the larger systems what they are most concerned is support of standards
23:36 and unfortunately, we haven't had enough investment in Koha yet to do a good job of that
23:36 chris we could just lie like the other vendors do
23:36 kados hehe
23:36 ha!
23:37 thd rach: yes that can be quite true.  I tried to demonstrate a partly working unattractive mockup against an attractive but functionally deficient system and the person was only exclaiming the virtues of the appearance of the other functionally deficient system
23:40 chris: some people have suggested to me privately that Koha already is lying with claiming to support MARC where that claim is not qualified.
23:40 chris ah well
23:42 rach so clearly the big libraries still have lots of funding - because they can afford to stand on their principles, whereas smaller libraries who are getting squeezed perhaps appreciate the pragmitism a bit more.
23:42 I'm guessing that chipping away at the big libraies is all we can do - continue to improve, continue not to go away
23:42 that's been our approach anyway
23:42 but it's not a get rich quick scheme I will admint
23:44 thd chris: Other vendors pursue significant independent capital beyond what comes from their customers in license fees and maintenance.  They all seemed to have had much more working capitol of their own when starting.
23:45 rach and this would contribute to why they aren't open source :-)
23:46 chris yep, if one of those vendors with a fully functioning, compliant system released it under the gpl id start working with that
23:47 thd rach: It could still be done for open source.  However, convincing a banker or another investor that open source is a better investment is difficult.
23:50 rach has someone tried?
23:51 thd Investors usually want to acquire an interest in the assets for security.  The source code and contracts are the only significant securable assets in proprietary software companies.
23:51 kados um ... so there's always Evergreen ;-)
23:52 rach maybe the marc hangups are just an american thing
23:52 sorry guys
23:52 paul seems to be run off his feet
23:52 thd kados: Evergreen has made some of the same mistakes about standards as Koha has.
23:52 rach have you considered moving :-)
23:56 thd rach: investors in GPL software companies cannot acquire any greater interest in the source code than the rest of the world leaving only the limited contracts as security.
23:58 rach: significant investment in OSS companies for code development has mostly come from other companies wanting to use the software themselves.
00:00 rach: So you just need to find some big businesses that want a library system that can be as easily customised as Koha.
00:01 rach yep that's pretty much who we look for
00:02 and we do a lot of non library work as well  - which adds to our general credibility as contractors
00:03 thd rach: Do you have more business library customers than non-business libraries for Koha?
00:03 rach in round numbers yes
00:03 as in - more actual people
00:04 more clients - in $ terms probably about the same
00:05 certainly more business/private libraries than public libraries by a lot
00:07 but we often do less for them
00:07 or bundle koha with other services more
00:14 thd rach: In the US, the business libraries are focussed on serials first and MARC second.  Bridging the gap to appeal to businesses, as the most likely customers to consider investing in Koha, would mean a lot of development work first for the very features that Koha has the least sufficient development now to appeal to the US business library market.
00:15 rach serials is what most businesses are interested in - which is why we're really happy to get a business client who wants us to work on them with them
00:22 thd rach: Maybe between your customer and the two that kados has, part of that minefield can be cleared.  It would be unfortunate if the minefield were merely mapped around or only cleared in the centre, without leaving a through path.
00:23 rach hopefully, we're certainly going to try and marry up our work and make it as widely useful as poss
00:29 thd rach: Koha needs to demap some of those minefields in a joint operation so that everyone can frolic with building improvements that other systems do not have rather than apologising for, "well, not yet, someday; but look over here this feature is nifty".
00:30 rach that's part of what you've been doing isn't it?
00:30 or did I get that wrong?
00:30 thd rach: I have been mapping the minefields not demapping them yet :)
00:31 rach: It is dangerous to demap them before they have been cleared :)
03:02 osmoze hello
03:36 thd hello osmoze
04:08 good morning paul
04:08 paul hi thomas
04:10 thd paul: what do libraries do for their UNIMARC copy catalogued records from BnF which have both 700 $a $b?  I know that is easily concatenated to just $a if it needs to be.
04:12 paul: I am just asking if you have written a script to do that concatenation and hidden it somewhere in Koha.
04:13 paul: also, is there an SQL update script for 2.2.4?
04:22 paul: sorry, I see the that the SQL files are identical between 2.2.3 and 2.2.4.  I had thought there would be minor changes.
04:32 paul thd : when you upgrade your version, koha runs updater/updatedatabase
04:32 same thing when you install, it installs 2.2.0 official DB, and update it
04:33 that's why the koha.mysql doesn't change.
04:33 (in 2.2 branch, will be different in 3.0)
04:35 thd paul: does 2.2.x have no provision for adding a column to a table for koha.update?
04:35 paul ???
04:37 thd paul: Where would the SQL for new columns or new tables go for 2.2.3 -> 2.2.4 if there had been any?
04:37 paul there are.
04:38 everything is in updater/updatedatabasE. but it's not SQL. it's perl script (& an intelligent one : checks what it has to create and do only what's needed)
04:39 thd paul: I was just about to do a diff on that file as I had noticed that the file size had changed.
05:03 paul: I see what you mean now by not SQL.  You do not consider intelligent generation of SQL statements from a Perl script to be SQL.  For you, an SQL file with nothing but blind SQL statements would be SQL.  Intelligent SQL does work better than trying to accomplish the same task in an SQL file blindly with brute force by dumping the data, dropping the tables, creating new tables, and reinserting the data.
06:40 So the default OPAC template is now only good for non-MARC Koha.
07:34 osmoze paul, as tu un petit moment ? J ai un probleme avec le fichier de retour bdp, dans la 2.2.3 et la 2.0 ...Je comprend plus :(, en attendant, vais installer la 2.2.4 en remplacement de la 2.2.3
07:49 paul osmoze, je suis là
08:02 osmoze coucou paul
08:02 je comprend pas, le script (nettoi_bdp) trouve pas les codes barre
08:02 :(
08:03 paul envoie le script ET le fichier BDP par mail stp.
08:05 osmoze ok :) je fini l install de la 2.2.4 avant ^^
09:50 thd paul: why is the itemcallnumber preference missing from demo.koha-fr.org ?
09:56 paul: it is not there at the moment.  I was hoping to check whether it worked there.
10:01 paul: the value does not appear for me unless I do something wicked such as swapping the mapping of items.itemnumber for items.callnumber.  Then the subfield is using a special reserved name called by the template.
10:03 paul: do you have any libraries that use this feature?
10:04 paul f
10:05 timing Hello we are a public school district with 7 elementary libraries, 2 middle school libraries and 1 high school library
10:05 and we are looking at koha
10:06 paul good idea. where are you located ?
10:06 (country at least)
10:06 timing does any one have this same setup and would like to answer some questions
10:06 USA, burleson, texas
10:07 paul maybe, probably. I'm Paul Poulain, Release MAnager for 2.x branch. And joshua / kados, the release manager for 3.0 is never far.
10:07 i'm french & joshua is from Nelsonville, Ohio.
10:08 timing just the guys i need
10:08 paul throw your question.
10:09 timing we currently use Follet and each library has its own database and marc records
10:09 kados hi timing
10:09 paul hehe... joshua never sleeps. 24/7 on this channel ;-)
10:09 timing hello kados
10:10 kados one of the libraries I manage used Follet many years ago
10:10 what are your questions?
10:11 timing I really want to use koha and we have 10 libraries with seperate databases and marc records
10:11 kados right
10:11 timing we want a system  that will allow us to seperate the campus libraries but allow for additional searches
10:12 to borrow
10:12 kados so a consortium of sorts eh?
10:13 timing like if a student looks for harry potter he will see if it is on his campus if not search for other campus
10:13 kados right ...
10:13 do any of your libraries have branches?
10:14 timing each school is its own branch
10:14 7 elem 2 middle and 1 high shcool
10:14 school oops
10:15 I see where to set up the braches but not really sure how to set up database and import marc records for each branch
10:15 kados ahh ...
10:16 well, the catalog is central to all branches
10:16 though it would be very easy to specify which branch a set of records belongs to
10:17 as far as bulk import, there is a command-line tool called 'bulkmarcimport'
10:17 it takes MARC records and imports them into Koha
10:17 timing but if student searches for a book and the book is not at his branch does it show all other branches that have it
10:17 thd kados: can he not have a simple modification that is set to only search other branches if the results are empty for the local branch?
10:18 kados yes
10:18 to both ;-)
10:18 timing: what we'd like to have, is full support for 'consortiums'
10:18 timing: but so far no libraries using Koha 'need' that feature so we haven't had a sponsor
10:19 thd kados: has not hdl been creating that?
10:19 kados thd: no ... slightly different ... hdl is working on 'independent branches' AFAIK
10:19 paul thd : no, hdl added feature for independantbranches, that makes each branch independant from a cataloguing point of view.
10:20 not really what is requested.
10:20 thd and that is in 2.2.4
10:20 kados timing: so if you're interested in contributing a major feature to Koha that'd be one option ;-)
10:20 timing so what are we looking at
10:20 kados timing: if that's not possible, you may be able to get away with using the current 'branches'
10:22 it's hard to say how much it would cost without taking some time to spec it out
10:23 but we're not talking hundreds of thousands or anything ;-)
10:23 timing well if we get something together I might have a large number of schools that would move to koha
10:24 thd Is there a my branch conception for the OPAC currently?
10:24 timing I have started a small company called open4education and we are working on open source solutions for education for Texas
10:25 kados cool!
10:26 timing I really like koha and would like to get something rolling towards a Follet replacement
10:26 lots of schools use it in Texas
10:26 kados yep
10:27 timing love liblime by the way I have visited your site several times
10:27 kados thx
10:28 thd timing: are you http://open4education.com/ 404 error?
10:29 JYL57 paul : Salut Paul, t'as une minute ?!
10:29 thd s/404/403 and 404/
10:30 paul zyva (en private)
10:30 kados heh
10:32 timing yeh we are working on it and have since changed servers
10:32 thd timing: Is http://www.open4education.com/ your website?
10:32 timing thd: yes
10:32 We just got started
10:33 only three of us and not enough time in the day
10:33 thd timing: understood
10:33 kados timing: how's business in Texas?
10:33 timing trying to find the best solutions to fit our needs
10:35 kados:not good since the government has locked up paying teachers until late October
10:35 kados yikes!
10:36 timing no budget releases or anything
10:36 yeh
10:36 paul yikes ! if someone tries this in France, there will be a revolution !!!
10:37 thd timing: Is the Texas state treasury short of money just now or is there no contract with the teachers union?
10:37 timing Judge says if no answer by late Oct all public school must shut down
10:37 kados ha!
10:37 timing then i would really have time for open4education
10:37 kados that's simply barbaric!
10:38 timing yeh tell me
10:38 thd timing: What is the precipitating cause?
10:39 JYL57 kados: Sorry to disturb you but I was wondering if progress has been made on the Fines topic lately ?!
10:39 timing terrible legislator's not worried about our children i guess
10:40 kados JYL57: chris committed a fix but it didn't completely fix the problem I'm having
10:40 JYL57: it's on my 'todo' list ;-)
10:40 timing well i have to have at least one school up as a test bed by end of month
10:40 paul (on top or bottom of the list ? :-D )
10:40 JYL57 I'm now on this topic too, because people want to start using fines here also !:-!
10:41 kados paul: top because a client needs it ;-)
10:41 thd timing: Funding is available for the rest of the government, just not teachers?
10:41 kados but this week I won't have much time to work on it
10:41 timing correct just not public school
10:42 JYL57 kados: if tests are required I can help
10:42 timing they got raises to all the other govermental agencies but not schools
10:43 JYL57 kados : I've looked at fines2.pl a few months ago...
10:43 timing does anyone have the exact break down of what the 14 digit barcode is about vs the 10 digit
10:44 we are currently using both and by my understading we need to merge to the 14 A.S.A.P
10:44 thd timing: that is an EAN barcode
10:45 kados JYL57: great! let's talk again about this early next week
10:45 timing I will be meeting with our test librarian today to discuss what koha will do or what follet is doing vs what we can or cannot do with koha
10:46 JYL57 kados : Ok, just time for me to upgrade to 2.2.4 and update my Debian Sarge a little...;-) See you
10:46 thd timing: 2 or 3 character country country code, product code plus id, and check digit.
10:46 kados JYL57: sounds good ;-)
10:47 timing thd: can I find this online some place
10:47 to show the librarian the break down
10:48 thd timing: yes there is a good reference I posted to koha-devel
10:49 timing thd: thnks
10:50 thd timing: The barcode generator most accessible in Koha was changed from EAN to 128 symbology
10:50 timing I am completely new to this library stuff so bare with me
10:51 the difference is what from EAN to 128 symbology
10:51 if we have 14 digit barcodes will this work
10:54 thd timing: code 128 is free form and EAN is structured fur use with UPC labelling but they are essentially both the same symbology
10:55 timing thd: i see, so we would be able to segregate schools based on the barcode
10:56 thd timing: There is no library standard barcode unless you mean the ISBN code which is moving from ten digit code 128 to EAN-13
10:56 timing I guess
10:57 we have mostly the ten digit and where told that we needed to move to a 14 digit barcode
10:58 indradg timing, we are using the code 128 to segregate the different types of users in our library (based on programs - as we are an Univ.) in our member mgmt... guess it will work seamlessly for lib items too
10:58 thd timing: for using barcodes in a library system you simply assign the code to the item holdings in the book record along with the school or library to which it relates
10:58 timing the marc records that follet uses will have the barcode info in that record correct
10:59 I think our problem is that we used the same barcode at 8 differnt campus libraries
10:59 thd indrag: do you use a sequence expressed in the code itself for a distinction similar to a manufacturer code?

← Previous day | Today | Next day → | Search | Index

koha1