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 russ doh 21:14 russ 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 thd 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 thd 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 russ 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 kados is that we've only done the bare minimum to address the needs of a specific client 21:50 kados without stepping back and looking to the future in terms of what needs to happen for bigger clients down the road 21:50 kados 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 kados but I agree it doesn't apply in other areas where we're actually leading the pack 21:51 kados like interface design for instance 21:51 kados and use of templates 21:51 kados 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 rach "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 kados unless 21:52 rach The serials yes is insufficient 21:52 rach 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 kados 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 chris then its all interface, which is easy 21:54 chris correct me if im wrong 21:55 chris 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 chris 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 chris so for public libraries, which issue serials 21:56 chris 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 chris 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 chris its just one of the many things wrong with MAR 22:01 chris 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 rach well it's what I understood by what he said to Kados a few minutes ago 22:02 rach YMMV 22:03 thd rach: The workaround is to create multiple linked holdings records before the size becomes too large. 22:03 thd rach: YMMV? 22:03 rach your millage may vary 22:04 rach - umm seems to mean you may have a different experience/understanding 22:05 rach 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 rach along with IANAL and IANAP 22:06 rach 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 thd rach: I have probably[D[D[a[C[C[C deciphered YMMV before when preceded by a 'but'. 22:11 thd rach: Multiple linked records was a suggestion. I have not answered on the list yet to the recent question about serials. 22:17 thd 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 chris there are no more features planned for 2.2.x 22:19 chris 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 rach 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 thd 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 rach 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 chris 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 rach but the point being that our more pragmatic development style has got us a library system that libraries can acutally use :-) 22:50 rach 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 rach 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 thd 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 chris 99% of our work is doing just that 23:09 rach surely that's what all library vendors seem to do 23:09 rach 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 chris 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 rach and often pay a deposit 23:10 chris i paid for my lounge suite before it existed 23:12 chris and there is nothing unusual at all about commiting to pay for something when it does exist 23:12 chris it happens all the time 23:13 chris 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 rach it's a long slow haul to prove yourselves etc 23:16 rach 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 thd 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 thd 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 thd 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 rach 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 kados 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 kados 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 thd 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 rach 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 rach that's been our approach anyway 23:42 rach 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 rach sorry guys 23:52 rach 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 thd rach: significant investment in OSS companies for code development has mostly come from other companies wanting to use the software themselves. 00:00 thd 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 rach 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 rach as in - more actual people 00:04 rach more clients - in $ terms probably about the same 00:05 rach certainly more business/private libraries than public libraries by a lot 00:07 rach but we often do less for them 00:07 rach 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 rach or did I get that wrong? 00:30 thd rach: I have been mapping the minefields not demapping them yet :) 00:31 thd rach: It is dangerous to demap them before they have been cleared :) 03:02 osmoze hello 03:36 thd hello osmoze 04:08 thd 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 thd paul: I am just asking if you have written a script to do that concatenation and hidden it somewhere in Koha. 04:13 thd paul: also, is there an SQL update script for 2.2.4? 04:22 thd 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 paul same thing when you install, it installs 2.2.0 official DB, and update it 04:33 paul that's why the koha.mysql doesn't change. 04:33 paul (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 paul 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 thd 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 thd 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 osmoze je comprend pas, le script (nettoi_bdp) trouve pas les codes barre 08:02 osmoze :( 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 thd paul: it is not there at the moment. I was hoping to check whether it worked there. 10:01 thd 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 thd 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 timing and we are looking at koha 10:06 paul good idea. where are you located ? 10:06 paul (country at least) 10:06 timing does any one have this same setup and would like to answer some questions 10:06 timing 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 paul 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 kados 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 timing 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 kados do any of your libraries have branches? 10:14 timing each school is its own branch 10:14 timing 7 elem 2 middle and 1 high shcool 10:14 timing school oops 10:15 timing 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 kados well, the catalog is central to all branches 10:16 kados though it would be very easy to specify which branch a set of records belongs to 10:17 kados as far as bulk import, there is a command-line tool called 'bulkmarcimport' 10:17 kados 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 kados to both ;-) 10:18 kados timing: what we'd like to have, is full support for 'consortiums' 10:18 kados 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 paul 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 kados it's hard to say how much it would cost without taking some time to spec it out 10:23 kados 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 timing 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 timing We just got started 10:33 timing 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 timing 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 timing 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 kados 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 timing 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 timing 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 timing the difference is what from EAN to 128 symbology 10:51 timing 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 timing 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 timing 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?