Time Nick Message 03:17 Amit heya chris 03:21 chris hi Amit 06:56 kf good morning #koha 06:58 Ropuch Morning #koha 06:58 kf hi Ropuch :) 07:20 Amit heya kf, Ropuch 07:38 kf hi Amit 07:42 chris wow that was fairly random of the national library 07:52 kf hm? 07:53 chris email to koha-devel, for katipo but to the whole list, i dont think they understand Koha :) 07:53 chris to use to proprietary vendors 08:12 kf ah 08:12 kf perhaps it's an old entry in their address list 08:13 chris hmm cant be that old, we only shifted the lists recently :) 08:17 kf chris++ thx for the reminder mail :) 08:35 kf chris: pootle seems a bit unhappy: An error has occurred. Thank you for your patience. database is locked 08:35 kf tried to change my account settings 08:36 chris i officially hate django and pootle 08:36 kf :( 08:36 chris there's probably nothing i can do about that 08:37 kf I get an internal server error when I click on logout 08:37 kf I was not able to deny/accept suggestions and wanted to check my permissions 08:38 kf kartouche seemed more stable, but the search was missing 08:38 chris and it wasnt being developed, and had about 1/10th the number of people using it 08:39 chris i tried restarting it 08:39 chris it might be better now 08:39 kf ok, thx 08:40 kf yep, seems better 08:41 kf yay - can edit suggestions now :) 10:06 chris quiet tonight 10:19 kf lunch time :) 11:39 kf hi jwagner :) 11:39 jwagner Hi kf 12:09 Fred Hello 12:10 kf hi Fred 12:13 Fred Is someone having a clue about an OPAC displaying no results while in the meantime the staff client works perfectly? (got some lines in error log too about : HTML::Template::Pro:in TMPL_LOOP at pos 410: PARAM:LOOP:next_loop(0): callback returned null scope) 12:17 kf Fred: which koha version? problem happens for all languages? xslt on? 12:20 Fred xslt off, just trying it in fr 12:21 kf do you have the same problem with english? 12:22 kf I am running in a lot of translation related problems, so this is the first thing I check 12:23 Fred no did not try the english version yet 12:25 Fred no change with english 12:31 kf which koha version? 12:34 Fred 3.01.00.140 12:35 kf hm 140 is not current 12:36 kf this is not a stable version and not the current HEAD 12:38 Ropuch Hm, back then with 3.0.x turning hidelostitems on worked in some cases 12:40 Fred ok 12:43 kf someone using patron notification of new issues (serials)? 12:49 Fred not yet 12:53 Fred i ve two 3.01.00.140 installed and only one got that problem with OPAC, intersting :) 12:53 kf nengard: around? 12:53 nengard yes 12:54 kf i was wondering if you have an example notice for new issues arrived notices 12:54 kf and if it would be a good idea to add one to the sample notices 12:55 nengard I don't ... koha doesn't have that ability yet ... does it? 12:56 kf hm, if you add a notice to the sub you get a link in the opac where you can subscribe to email notifications 12:57 kf so far it looks quite good - but the notice I chose is RLIST 12:57 kf not really what I want it to look like, I will try to invent one 13:01 kf nengard: I will let you know if koha can do it :) 13:01 nengard oh wait you're talking about new issues of serials? 13:02 nengard that's the routing list 13:02 nengard or are you talking about new items in general 13:02 kf new issues of serials 13:02 kf subscribing to email notification via opac 13:12 jcamins Good morning, #koha 13:12 jcamins Fred: there's something in the manual about searches working in staff but not OPAC. 13:12 jcamins Sadly I can't remember what, or where. 13:12 Fred Hello 13:13 Fred Oh really? that's great! i will check it right now then, thanks! 13:13 jcamins Wait, I think I remember! 13:13 jcamins OPACSuppress. 13:15 Fred got it 13:16 Fred wow great! it works perfectly now! 13:17 jcamins If only I could type. 13:17 jcamins But you managed to find it even though I told you the wrong name. 13:18 Fred :) 13:18 Fred thanks a lot for that essential clue 13:24 kf jcamins++ :) 13:26 kf Undefined subroutine &C4::Letters::GetMember called at /usr/share/koha/lib/C4/Letters.pm line 278. :( 13:28 jcamins kf: That doesn't sound good. :/ 13:29 kf no 13:29 kf still trying to send me an email notification 13:30 kf I get this error now when receiving new issues 13:36 rhcl how's it going? 13:36 kf jwagner: what is curriculum used for? :) 13:36 rhcl oops 13:39 jwagner kf, it's a feature for schools -- the 658 contains curriculum terms, and this adds a search for them. 13:40 jwagner See the LC entry on the 658: http://www.loc.gov/marc/bibliographic/concise/bd658.html 13:40 kf ah 13:40 kf thx :) 13:41 kf we have no school libraries yet, but I they will be happy about it 13:41 jwagner It was one of our school library systems that requested it :-) 13:42 kf is the search option always shown? 13:42 jwagner It's under Advanced Search, More Options 13:43 jwagner Bug 5193 is more specialized 13:43 munin 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5193 enhancement, P5, ---, jwagner, ASSIGNED, Add specialized auction indexes and search options to Advanced Search 13:44 jcamins jwagner: did you see bug 4480? 13:44 munin 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4480 normal, P5, ---, gmcharlt, NEW, MARC21 033 tag and Zebra date indexing 13:45 jcamins Specifically, 033 can contain the computer-readable auction date. 13:45 jwagner jcamins, no, I hadn't seen that one. But our site wanted separate fields for date, auction house, and code 13:45 jcamins Yeah, they'll still need those, but they probably also want the 033. ;) 13:48 kf :) 13:48 kf jwagner++ 13:48 jwagner This one is controlled by a syspref because not too many sites will want to work with auction catalogs. 13:49 jcamins Very sensible of them! 13:49 jcamins I don't want to work with auction catalogs, either! ;) 13:51 sekjal what we really need to for the Zebra indexes to be completely user-controllable through the staff client, but that's no small feat 13:51 jcamins That would be amazing. 13:51 kf yes 13:52 sekjal oh, and while we're at it, make Koha support more than just MARC for metadata 13:54 kf there is always a lot of room for improvement 13:55 sekjal I love that there's so much that can be done, but I hate that I don't have enough time to do it all 13:55 sekjal fortunately, it's not just me coding for this project :) 13:55 kf me too :( 13:56 jcamins Does Koha support subdivision authority records? 14:02 kf jcamins: I have no idea what this is :) 14:03 jcamins For example: 14:03 jcamins 600 $aWashington, George[$xCoin collections$vCatalogs] 14:03 jcamins An authority record for the part of the heading that's in brackets. 14:05 kf hm 14:05 jcamins I haven't tried it yet, but I thought someone might know the answer. 14:05 jcamins I also don't know how I would try it. 14:16 rhcl hey munin, go fetch me bug 4239 14:16 munin 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4239 enhancement, PATCH-Sent, ---, gmcharlt, NEW, Allow holds on multiple items of selected titles 14:16 kf rhcl: munin does even know marc 14:16 kf @marc 001 14:16 munin kf: The control number assigned by the organization creating, using, or distributing the record. The MARC code for the organization is contained in field 003 (Control Number Identifier). [] 14:17 kf @eightball will I be able to configure sendmail? 14:17 munin kf: You're kidding, right? 14:18 jcamins kf: that's why I use postfix. 14:19 kf how easy is it? 14:20 jcamins Easier than sendmail, anyway. 14:20 jcamins Do you know, in ten years I have never managed to get sendmail to work? 14:20 jcamins I still need to set postfix up on my new server, but it wasn't too hard last time I did it. 14:20 kf ok, I will keep it in mind 14:21 kf will ask a coworker to help me tomorrow 14:21 jcamins Exim is supposed to be nice too. 14:21 wizzyrea I prefer postfix 14:40 rhcl I prefer gmail 15:03 hilongo Hello koha fellows :) 15:04 hilongo I have a question about search results 15:06 hilongo I noticed that they are not really sorted ... by relevance nor any other criteria 15:23 nengard hilongo it is sorted by relevance - but it's relevance according to zebra 15:23 nengard it's a magic algorithm that no one has been able to define to me yet ... 15:29 Fred someone told me it s about black magic from Denmark... 15:30 Braedon ask the blotch. The blotch knows! 15:31 * Braedon realizes this is probably the wrong channel for that reference... 15:32 hilongo hmm.. I see ... that is what I felt after trying it to do what I want :P 15:39 hilongo And how about Stopwords? Cause I don't want zebra to be retrieving records that contain 'of' 'the' etc 15:39 hilongo I see the syspref to ignore them when searching, but only if Zebra is off 15:42 Braedon shouldn't zebra handle that itself? 15:48 hilongo maybe it does ... I have to deeper test it ... 15:49 Braedon http://www.mail-archive.com/koha-patches@lists.koha.org/msg00546.html 15:51 hilongo BUT .. what have me troubled now is that I have imported the records of a library, and they all apear in the last pages of a search result 15:52 jcamins hilongo: perhaps it's sorting by id? 15:58 wizzyrea but what if you have a book titled "the" 15:58 jcamins Much like "War and Peace" in a large university's next-generation discovery tool, you won't be finding it in the catalog. ;) 15:59 wizzyrea heh heh heh 16:00 hdl hilongo: by default, if no sort correct or error on zebra indexes, then relevancy is recordid 16:02 jcamins wizzyrea: actually, there's a poetry journal from the 70s called "The." 16:02 wizzyrea I know! 16:02 wizzyrea which is why I have come around to the "stopwords are bad" philosophy 16:03 jcamins I never did manage to find it in the NYPL catalog. 16:03 hdl hilongo: lower priorty 16:04 jcamins Of course, Koha doesn't easily provide the ability to do a full-field search, does it? 16:04 hdl But still, I worked on relevancy... And I think it got into 3.2 so maybe you could try and add all the indexes used there. It is in C4/Search.pm 16:05 hdl jcamins: does an xpath search an easily way for you ? 16:05 hdl /record/datafield[@tag="123"]/subfield[@code="a"] 16:06 hdl and enable xpath 16:06 jcamins You can use that for searching on the OPAC? 16:07 hdl in the big box : pqf= @attr 1=/record/datafield[@tag="123"]/subfield[@code="a"] Myvalue 16:07 jcamins Cool! 16:07 hdl will search for Myvalue in 123$a 16:07 jcamins Not the most user-friendly search method ever, but at least now I can do it. :D 16:10 hdl I think it could work 16:10 jcamins I don't need to do the search right now, but it's good to know it's possible. 16:11 cait hi #koha 16:11 hdl hi cait 16:11 jcamins Hello. 16:19 hilongo If I set defaultSortOrder and defaultSortField in SysPrefs .. shouldn't the idrecord relevancy be omitted? 16:20 hdl mmm no 16:21 cait hi hdl :) 16:21 hilongo Even more ... TO the left of the search results page .. there is a filter that lets you select a Library to see only the records belonging to that one 16:22 hilongo BUT .. it only lists the libraries that are visible on the current search result 'page' ... not all the libraries that have matching records 16:24 hilongo thus... with recently added library... not only their records appear at the last pages, but their library name is not even listed in the Library selector 16:25 wizzyrea hilongo: yep, that's very frustrating for those of us with more than 5 or so libraries 16:25 wizzyrea do you have a branch created for your new library? 16:25 wizzyrea have you actually created the library in koha? 16:26 hilongo Yes .. I have set up branch for the new library 16:27 hilongo if I skip to the last pages I can see the results belonging to it, and the library name is listed in the Filter 16:30 wizzyrea hehehe! 16:30 wizzyrea http://www.xtranormal.com/watch/7046237/ 16:31 wizzyrea My librarians are awesome 16:32 sekjal oooh, cake pans! 16:32 wizzyrea :D 16:33 wizzyrea I did a lightning round at our Tech day on xtranormal: I sold it by telling my librarians that "you know how you always want to make videos, but you never want to *appear* in the videos? This lets you do that" 16:33 wizzyrea and omg. They loved it. 16:34 wizzyrea someone told me that the library xtranormals were the first ones they'd seen that didn't include cursing. ;0 17:22 collum wizzyrea: That's cool! 17:22 collum The xtranormals and the cake pans. Both. 17:59 joetho general meeting less than one hour from now, correct? 18:00 cait yes 18:05 joetho thx 18:31 joetho T minus fifteen minutes, more or less. 18:45 slef hi all 18:46 gmcharlt hello folks 18:46 hdl hi 18:48 Colin evening all 18:48 nengard afternoon 18:48 chris morning 18:48 nengard hehe 18:48 gmcharlt meeting time 18:48 gmcharlt agenda is at http://wiki.koha-community.org/wiki/General_IRC_Meeting,_1_September_2010 18:48 gmcharlt and the agenda items are 18:48 gmcharlt Update on Roadmap to 3.2. 18:48 gmcharlt Update on Roadmap to 3.0. 18:48 gmcharlt Update on Roadmap to 3.4. 18:48 gmcharlt Koha Holdings data fields (9xx). 18:48 gmcharlt Follow-up on actions from General IRC Meeting, 11 August 2010. 18:48 gmcharlt Agree times of next meetings. 18:49 chris start with intros? 18:49 gmcharlt indeed 18:49 chris Chris Cormack, Catalyst IT, RM 3.4 18:49 * gmcharlt = Galen Charlton, 3.2RM 18:49 * cait = Katrin Fischer, BSZ, Germany 18:49 * nengard Nicole C. Engard, Doc Manager & ByWater Solutions 18:49 jwagner Jane Wagner, PTFS 18:49 * sekjal Ian Walls, ByWater Solutions 18:49 * hdl Biblibre, RMaint 3.0 18:49 * slef = MJ Ray, extremely overworked co-owner of software.coop Koha support 18:49 Colin = Colin Campbell PTFS-Europe 18:49 joetho Joe Tholen SEKLS / Kansas 18:50 * jcamins = Jared Camins-Esakov, consultant 18:50 thd Thomas Dukleth, Agogme, New York City 18:50 rhcl Greg Lawson, Rolling Hills Consolidated Library, St. Joseph, MO, USA 18:51 gmcharlt thanks 18:51 gmcharlt on to 3.2 18:51 gmcharlt on 8/24 BibLibre submitted a patch for bug 4310 18:51 munin 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4310 blocker, PATCH-Sent, ---, henridamien, NEW, No Migration for budgets from 3.0 to 3.2 18:51 irma Irma Birchall, CALYX information essentials, Sydney, Australia 18:52 gmcharlt regarding the upgrade of acquisitiosn budgets from 3.0 to 3.2 18:52 rafael rafael antonio, Consultant, Portugal 18:52 gmcharlt Colin: did you happen to have a chance to test that patch and determine if it results in a succesful upgrade of funds? 18:53 Colin No. I'll see what it does. 18:54 gmcharlt thanks 18:54 gmcharlt at this point bug 4310 is the primary blocker; the result I'm prepared to bump to 3.4 18:54 joetho you mean in the agenda, right? 18:55 gmcharlt joetho: wha? 18:55 gmcharlt no, the classification of the bugs 18:55 * wizzyrea Liz Rea NEKLS 18:56 chris result = rest? 18:56 hdl the rest of bugs ? 18:56 gmcharlt sorry, yes, "rest" 18:56 Nate Nate Curulla: ByWater Solutions (sorry im late) 18:56 hdl So bugs will now be declared in 3.4 18:56 chris id hope some could be fixed for 3.2.1 :) or 3.2.2 18:56 thd 'bump' is almost invariably ambiguous in actual usage 18:56 hdl And cherrypicker onto 3.2 ? 18:57 chris yep 18:57 gmcharlt yep, that would be up to chris_n 18:57 Colin are there any bugs in your queue for 3.2 not yet applied? 18:57 hdl maybe we should ask folks to try and send on 3.2 and 3.4 if 3.2 and 3.4 diverge enough 18:58 hdl Colin: who are you talking to ? 18:58 gmcharlt Chris Nighswonger has been pretty explicity that he will not permit that kind of divergence 18:58 Colin To Galen 18:58 gmcharlt and I hope we all work to hold him to that 18:58 chris lets all try to make it possible for him to do that 18:59 hdl Can you be more explicit in how we could help him ? 18:59 chris dont submit features for 3.2 18:59 hdl Yes... 18:59 gmcharlt Colin: at this point 4310 is my primary concern 19:00 chris everything goes to master, and is backported 19:00 gmcharlt since we're veering into 3.4 19:00 gmcharlt let's go to the next item on the agenda 19:00 * chris_n steps in late 19:00 hdl But sometimes new features helps some bug fixing 19:00 gmcharlt hdl: update on 3.0.x? 19:00 chris and remind him, if he does put features in 3.2 that arent in master, that its a bad idea and please take it out 19:01 hdl I had vacation for 2 weeks. 19:01 * chris_n nails in a few more nails into the "no new features in 3.2.x" lid 19:02 chris chris_n++ 19:02 gmcharlt chris_n++ 19:02 hdl And little time to package 3.0.7 and now, I would like to ask community if such a release would be really a good thing. 19:02 chris hdl: im not sure it would be 19:02 sekjal but new features that are already in HEAD would be alright to add to 3.2.x? Am I understanding that correctly? 19:02 gmcharlt sekjal: if they can be cleanly cherry-picked 19:03 cait chris_n++ 19:03 nengard hdl i don't see us needing it if 3.2 is around the corner.. 19:03 hdl Since imho, 3.2 release shouldnot be coming along with a 3.0 release 19:03 chris hdl++ 19:03 gmcharlt and any thing that involves a database update is carefully so that 3.0->3.4 and 3.2->3.4 woudl hvae the same result 19:03 chris that would just be confusing 19:03 slef Basic question: are there any really nasty bugs in 3.0.6? 19:04 hdl well, we still had some. 19:04 slef (I don't remember. We run git.) 19:04 hdl there are bugs with holdings 19:05 chris hdl: data loss bugs? 19:05 hdl No. 19:05 slef anything blocker or critical? 19:05 hdl But hold notices not being sent. 19:05 thd slef: the nastiest bugs are the ones essentially unreported especially if they are presumed to be features :) 19:05 hdl (which from a librarian pov would be not only critical) 19:06 gmcharlt if a bugfix release of 3.0.7 is warranted and ready to go, I don't have any particular objection to hdl doing it 19:07 gmcharlt not all 3.0.x users are going to want to jump to 3.2.0 instantly anyway 19:07 hdl But is there 3.0.x users ? 19:07 thd gmcharlt makes a good point that users may choose to wait before migrating to 3.2 19:07 gmcharlt hdl: presumably 19:20 slef There are 3.0.x users who approach software.coop for support/upgrades. 19:20 hdl we have some, but most of them are on a git version of 3.0.x 19:20 hdl now 19:21 hdl So 3.0.7 on the way 19:21 gmcharlt anyway - I think upshot is that if hdl wants to do a 3.0.7 release, no objections; if he doesn't want to, that would also be fine 19:21 gmcharlt cool 19:21 gmcharlt moving on to next item on agenda 19:21 gmcharlt 3.4 - chris? 19:22 chris right 19:22 rafael We in PT are now confident on 3.0.6 and would like to still some time with a stable environment 19:22 hdl tx rafael 19:22 chris so id like to open it up to people to start sending in patches for 3.4 19:23 gmcharlt +1 19:23 chris i intend to use a system like this 19:23 chris http://patches.workbuffer.org/ 19:23 nengard will patches sent to head that haven't made it to 3.2 be considered for 3.4? 19:23 chris yes 19:23 nengard k 19:24 chris i will try to fill that awaiting_qa directory with those :) 19:24 nengard sounds good 19:24 chris i would love for others to apply patches, sign off and resend them too 19:25 hdl would some branches not be more useful for ppl. 19:25 gmcharlt hdl: topic branches? yes, I would think so 19:25 hdl lik a qa brach ? 19:25 chris there will be branches too 19:25 hdl and ft branches ? 19:25 hdl ok 19:25 hdl good 19:25 chris its just a bunch easier to see a list of patches in a dir 19:25 slef I think we need some tracking. Looking at chris's link. 19:25 chris than git log 19:25 gmcharlt Colin: are you intend to set up a QA tree? 19:26 Colin That seems logical. I should probably look at what's been posted the last couple of months and not applied 19:27 hdl chris resending patches on list would rapidly mess all the interest of list, unless we agree on a tag in subject. 19:27 chris hdl: it would be better if people would send them first to someone else to signoff 19:27 hdl say [sign-off] or [tested] 19:27 chris then to the list 19:28 nengard chris who is that someone? 19:28 chris itd be nice to have patches to the list be signed off by at least one other person, if possible 19:28 chris nengard: different people all the time 19:28 nengard the idea being that at least someone else has looked at it? got it 19:28 chris usually there is at least one other person interested in the bug/enhancnement 19:28 jwagner How do people working on things know where/who to send patches to? 19:28 chris they talk 19:29 nengard :) 19:29 hdl hehe jwagner++ 19:29 chris attaching the patch to the bug 19:29 chris with a message please apply and signoff 19:29 chris is a good way to do it 19:29 jwagner That was a serious question, by the way. Are we supposed to go on the listserv every time? 19:29 slef chris: Can you somehow link to the mails on -patches as well as having files in that AutoIndex? 19:29 gmcharlt jwagner: it can be any number of approaches 19:29 nengard chris's answer was serious too i think 19:29 chris jwagner: id expect all ptfs patches to at least have 1 other ptfs person 19:29 gmcharlt formal relationships between entities to test each others patches 19:29 gmcharlt requests on IRC 19:30 gmcharlt on the mailing lists 19:30 sekjal my plan has been to put any specifications to which I'm developing up on the wiki, so folks can provide feedback, criticism, ideas, etc. then from the traffic on that page I'd have a good idea who's interested 19:30 jwagner Yes, chris and I crossed in midstream 19:30 jwagner His approach sounds feasible. 19:30 chris sekjal: good plan 19:31 slef It would be nice to crossreference the patches mails, the bugs and the release management process, but I'm unsure how best to do that. 19:31 chris at the moment, i sign off robins, he signs off mine at catalyst, i signed off one for wizzy the other day .. more of that would be good 19:31 Colin It would be a good idea where there's a default assignee in bugzilla that you ask them 19:31 chris Colin++ 19:32 gmcharlt ok 19:32 hdl sekjal: have been doing but sending a mail on koha-devel list to announce that could also be interesting. 19:32 gmcharlt upshot: chris will start accepting patches for 3.4; discussion of sign-offs 19:32 gmcharlt moving in the agenda 19:32 chris slef: bug ids in commit messages helps 19:32 gmcharlt we have 19:32 gmcharlt 4. Koha Holdings data fields (9xx). 19:33 chris ahh this was zeno 19:33 chris who isnt here? 19:33 gmcharlt right 19:33 thd I could comment 19:33 chris do you know what he was asking thd? 19:33 slef thd wrote a conversion guide back for 2.x, so it would be an interesting comment IMO 19:33 hdl I could too. 19:33 thd I remember the question which he posed on the mailing list. 19:33 gmcharlt thd: go for it 19:34 slef I'm looking for a link to the question. Which list? 19:34 hdl koha-devel and koha iirc 19:34 thd Zeno was asking about standardised use of holdings. 19:35 thd slef: search both koha and koha-devel for 995 in the subject 19:35 hdl To define default 9xx fields for Unimarc setup in all languages 19:36 slef http://comments.gmane.org/gmane.education.libraries.koha.devel/4775 19:36 slef key point: unimarc "on local fields English and French are not compatible" 19:37 thd I did not have time to give a nuanced answer but the answer which Zeno was given on the list is that it was up to the library to define the links between the Koha MARC holdings field and the items column in the database in an appropriate manner for the particular library 19:37 slef zeno's proposal "We re-write English setup in 9xx fields" so that they are compatible. 19:37 thd There are problems 19:37 gmcharlt I wonder how many English-speaking UNIMARC users there actually are 19:38 slef I think all current software.coop clients are MARC21, even some non-English ones, but davi might correct me on that. 19:38 hdl gmcharlt: in fact, UNIMARC english frameworks are installed by default. 19:38 gmcharlt but at least for indexing of item records, there would be a way to make it a non-issue, at least for item fields that are stored in the items table outside of more_subfields_xml 19:38 cait our german libraries are all marc21 too 19:39 thd Recommandation 995 is designed initially to facilitate interlibrary loans and is insufficient as holdings format. 19:39 slef cait++ 19:39 gmcharlt and that would be to change the serialization of the item records for indexing purposes 19:39 gmcharlt e.g., wrap bib MARCXML plus items expressed as XML 19:40 gmcharlt and use DOM mode for indexing bibs 19:40 gmcharlt at least in the context of the current Zebra setup 19:40 hdl thd: you can use non standard item subfields. 19:40 thd Fortunately, even the latest version of Recommandation 995 leaves some fields undefined. 19:40 rafael Continental European countries are mainly UNIMARC so to become KOHA universal we need to accept a common framework 19:40 thd hdl: yes. there are gaps in the standard. 19:40 gmcharlt that way, the specific 995, 952, etc. serialization of item records embedded in bib data is less relevant to indexing 19:40 hdl gmcharlt: this would also be quite interesting in order to get items out of biblioitems.marcmxl 19:40 chris s/KOHA/Koha/ :) 19:41 * chris has one of his pet peeves poked 19:41 hdl thd: very little gaps. 19:41 gmcharlt of course, as rafael implies, there would be data interchange reasons for UNIMARC users to achieve more consitency of 995 field usage 19:41 thd gmcharlt could you explain the XML wrapping idea more fully? 19:41 hdl http://www.adbdp.asso.fr/IMG/pdf_r995.pdf 19:42 chris so i think we might be getting off topic a bit 19:42 chris since this wont be done for 3.2 19:42 hdl definitely. 19:42 hdl But still, for 3.4 19:42 chris_n sounds like a list discussion to me 19:42 chris maybe move it to an rfc for 3.4 19:43 hdl getting out items from biblioitems should be given a try. 19:43 chris or an rfc and a list discussion :) 19:43 pastebot "gmcharlt" at 98.70.42.64 pasted "for thd - how a bib record could be sent to Zebra for indexing" (8 lines) at http://paste.koha-community.org/59 19:43 slef chris: but PTFS say it's KOHA and they own us, right? 19:43 * slef runs 19:44 * Braedon hides slef 19:44 cait not sure this was really necessary 19:44 gmcharlt chris: hdl: thd: yep, ultimately an RFC or list discussion 19:44 thd if the discussion scope is limited to 3.2 then I see no significant problem with Zeno's proposal other than French libraries for which 995 is relevant have a different mapping. 19:45 gmcharlt thd: if nobody is truly using the English UNIMARC setup, updating it to be a copy of the French 995 mapping (with different labels, of course), would be simple 19:46 gmcharlt depends, I guess, on the starting point for the libraries that rafael mentioned 19:47 thd The more interesting issue for me is the one brought up by ebegin about lack of consistency for numeric statuses in actual usage despite some values being defined in the code. 19:47 thd I think that more interesting issue is also for 3.4 19:47 davi slef, you are right. All are MARC21 19:48 rafael which countries are using French mapping or English mapping ? 19:48 gmcharlt thd: that can only go so far - common values for some statuses is achievable, but at some point there will be additional ones that a library might add to represent purely local considerations 19:49 slef Can we run a call for people to comment on koha-community.org if they use English UNIMARC? Announce it to koha and code4lib and maybe others. 19:49 thd English UNIMARC was created as noted in the file comment from some unchecked work of a librarian where I only tried to follow the standard for Recommandation 995 instead of French Koha use. 19:49 hdl koha-infos 19:49 slef rafael: do you have English UNIMARC mappings? 19:49 slef davi: thanks for the info 19:49 gmcharlt slef: zeno (or whoever) could certainly put on a blog post on k-c.org to try to solict more feedback 19:49 thd As noted in the comments I do not consider unchecked work safe for actual use. 19:50 thd I know there are important things missing from the English framework but only added the most obvious. 19:50 Colin In a few years of experience I've only encountered Unimarc in Francophone Europe, Portugal, Italy 19:50 slef rafael: I meant, do you have libraries using the English UNIMARC mappings? 19:50 rafael well I was trying to follow English to maintain as much compability as possible and it works and is enough but may be we could try a common framework for 3.4 19:51 slef Colin: moi aussi... les allemands sont plus sages ;-) 19:51 hdl Portugal and Italy are not francophone. 19:51 cait slef: can you translate? 19:51 gmcharlt I think for the moment we've talked this one out --- additional discussion to blogs or email 19:51 hdl and Russia and Georgia are also using UNIMARC 19:51 slef hdl: imagine a + sign, not a union 19:51 thd fredericd had told me that one of his libraries was using it. I cautioned him about incompleteness. 19:51 Colin That was a list francophone is Belgium Switzerland etc (part of in both cases) 19:51 slef cait: probably. 19:52 gmcharlt moving on in the agenda 19:52 gmcharlt action items from General IRC Meeting, 11 August 2010. 19:52 * slef hides in shame 19:52 thd I have had delay from my computer but I am using it now. 19:52 rafael We follow as much possible MARC concepts and UNIMARC for bibliographic description but 9xx could be common to everybody 19:52 gmcharlt I think main pending one would be organizing vote for relicensing 19:53 thd Tonight, I should post a message which SFLC sent me a month ago. 19:53 davi Also, I think Koha should not use 952, as it is OBSOLETE as per http://www.loc.gov/marc/bibliographic/bd9xx.html 19:53 davi ? 19:53 slef I've got at least two very unfun items on my todo list about the relicensing: vote format and one of the summaries. Nothing blocking them really, just the volume of paid work I've got to do. 19:53 gmcharlt and at this point ... action on part of people to set up vote, define ballotts, etc. will determine if/when it takes place 19:53 thd Sorry that ###gparted caused me such trouble in fixing my partitions. 19:53 slef davi: that's a different discussion. Add it to next agenda? 19:54 davi s/use/encourage the use/ 19:54 davi ack 19:54 slef rst 19:54 davi yes, please add to next agenda 19:54 gmcharlt davi: general comment - 9xx fields are specifically for local use 19:54 davi I know but 19:54 slef ok, I'll probably mention the 952/852 thing on list 19:54 davi 952 is OBSOLETE as per http://www.loc.gov/marc/bibliographic/bd9xx.html 19:55 davi and so maybe Koha should not encourage its use 19:55 gmcharlt davi: I suggest reading the description of that tag on that document 19:55 rafael even if for local use do they have any impact on Koha scripts ??? 19:55 hdl and MARC is dead... ;) 19:55 gmcharlt LC is referring to an antique CAN/MARC usage; has nothing to do with Koha at this point 19:55 slef rafael: bulkmarcimport takes item info from 952s 19:56 rafael so we need to have a common framework.... 19:56 gmcharlt rafael: more precisely, bulkmarcimport uses what ever tag has been defined as the item tag per the MARC frameworks/item mapping in effect in the Koha database 19:56 gmcharlt rafael: so 952 if you're a MARC21 user, 995 if you're a UNIMARC user 19:56 gmcharlt or something else if you've customized your frameworks 19:56 rafael thanks 19:56 hdl but only with one tag for item information 19:57 gmcharlt final item of the agenda - decide next time 19:57 thd davi: gmcharlt had the answer for you. I can explain more after the meeting. 19:57 davi ack, thanks thd 19:57 gmcharlt the first Wendesday in October is 10/6 19:57 gmcharlt 10:00 UTC+0 ? 19:57 * gmcharlt says, blearily in advance 19:58 gmcharlt so ... 19:58 thd 10 UTC is a very good time :) 19:59 thd +1 19:59 davi +1 19:59 hdl what time is it for you gmcharlt? 19:59 gmcharlt hdl: too dang early 19:59 hdl 4AM ? 20:00 chris 11pm for me, thats ok 20:00 thd gmcharlt: There is plenty of time to sleep after the meeting :) 20:01 chris_n thd: only if you don't go to work at a location too distant 20:01 gmcharlt hdl: something like that; main reason is that we've been running the past few meetings at a bad time for those in India, so it's time to do a 10:00 UTC 20:01 hdl +1 then 20:01 indradg gmcharlt, +1 20:01 slef You can practice for kohacon jetlag early! 20:01 * chris_n would rather that than 6 or 7 utc 20:01 * wizzyrea will attend from bed 20:01 chris_n +1 20:01 thd It is only fair to provide for globally appropriate times 20:02 irma +1 20:02 gbengaada +1 20:02 gmcharlt ok, so it's set at 6 October, 10:00 UTC+0 20:02 indradg yes... its 1:32 in the morning here in India, so +1 20:02 davi +1 20:02 indradg :) 20:02 gmcharlt thanks all - meeting adjourned 20:02 hdl hi indradg. 20:02 * wizzyrea realizes that is the week before she leaves for NZ... squees a little 20:02 hdl see you. 20:03 thd davi: I can explain more about 952 now 20:03 * hdl can't wait meeting all those ppl 20:03 davi thanks thd 20:04 slef squees? 20:04 davi Just I wanted to noted that maybe Koha should not encourage the use of 952 as it is marked as OBSOLETE at http://www.loc.gov/marc/bibliographic/bd9xx.html 20:04 davi What do you think about it thd ? 20:04 wizzyrea it's an expression denoting a squeal-like vocalization 20:05 chris ok time to get the kids ready for the day 20:05 jcamins davi: the 9xx fields are all local. Anyone can use them for whatever they want. That page from LC is talking about the old CANMARC standard. 20:05 thd 952 was chosen by Nelsonville Public Library sponsoring paul_p's work to create a MARC version of Koha for the first time out of non-MARC Koha. 20:05 cait davi: 9xx fields are local, not part of the standard 20:05 davi jcamins, Do you knwo some page which document the non-old MARC21 standard? 20:06 jcamins The LC website. 20:06 davi thanks 20:06 jcamins That *specific* page describes fields that were used in the old standard. 20:07 davi good good, thanks 20:07 jcamins We need to use a local field for holdings information, because the standard field doesn't have enough information. 20:07 jcamins @marc 852 20:07 munin jcamins: Identifies the organization holding the item or from which it is available. May also contain detailed information about how to locate the item in a collection. (Repeatable) [a,b,c,e,f,g,h,i,j,k,l,m,n,p,q,s,t,u,x,z,2,3,6,8] 20:07 thd Unfortunately, libraries use 9XX to do important things which creates something of an extended standard and some libraries somewhere have old records with 952 data from CAN/MARC. 20:07 irma http://www.loc.gov/marc/bibliographic/ 20:08 thd davi: The problem with using 852 is that what is needed for Koha does not match the usage of 852. 20:08 * chris wanders off 20:08 davi thd, Should Koha be modified to adapt to match the standard? 20:09 davi I think the standard should be more important than the usage? 20:09 thd I tried to make 952 usage more compatible with 852 for 3.0 development but my attempt at better conformity with the standard lost out to the need to include columns which are not standard in 852. 20:09 irma davi, after kohacon10 @ the hackfest some some work will be done on this 20:10 jcamins davi: I don't think that's reasonable, because 952 contains a lot of important information which is not in the 852. 20:10 davi thanks 20:10 gmcharlt davi: jcamins is right - there is *no* standard serialization that covers everything one might store in an item record, be the ILS Koha or anything else 20:10 thd davi: Koha should be able to support standard holdings which uses multiple fields not just 852 for MARC 21. 20:11 slef the standard should be more important than the usage, but sometimes performance (CPU or developer) needs override both 20:11 davi I see 9XX is needed as exposed by somebody above 20:11 cait thd: standard holdings are a bit of a nightmare and still missing fields 20:11 cait thd: our union catalog can export marc21 holdings 20:11 slef it would be nice if Koha tools imported/exported 852s more easily - conversion is not the most fun sort of work 20:11 thd davi: The one MARC field design limitation requires a design change which is present in the LLEK fork and in a fork in Cyprus which inspired the feature in LLEK. 20:12 davi About rel-licensing, if any 20:13 davi Has been AGPLv3+, GPLv3+, proposals written? 20:13 davi so I can review the AGPLv3+ ? 20:13 thd cait: Do you mean that standard MARC 21 holdings does not track everything which the ILS tracks for holdings? 20:13 cait thd: at least I am not sure about it 20:14 cait we don't have all information in the union catalog, so I don't know all fields 20:14 thd davi: the *GPL discussion has merely been delayed by my broken and now fixed computer. 20:14 gmcharlt thd: cait: they don't - simple as that. for example, the no MFHD or 852 standard encompasses the concept of an item statistical category 20:14 cait but I think fields as overall checkouts, holds, renewals, last checkout date will not be part of the standard 20:15 gmcharlt exactly 20:15 davi ack thd 20:15 thd I do not think it important for a holdings standard to retain all transient data. 20:16 cait It's part of the item data is all ils I know 20:17 gmcharlt thd: who is to define what is important or not for a data migration or, more generally, data interchange 20:17 thd gmcharlt: everything is important for data migration 20:17 gmcharlt your "transient data" is my discovery system's gold mine of statistical information that can improve search results, for example 20:17 thd losing data is a sin 20:18 thd data interchange importance is merely what people agree is important with whomever they wish to interchange data 20:19 indradg hdl, hi 20:20 thd The problem is that one instance of [0-9a-z] from one field is not enough for everything which people want for holdings even on a long term basis and we need some method around that difficulty at least where indexing the data is important. 20:23 cait ok, I already started on the upper case letters ;) 20:23 thd Koha 3.0 design presumed that one instance of [0-9a-z] had to be enough because that was the existing design in Koha and the desire was to release 3.0 sooner than would have been practical with a redesign of holdings. 20:23 davi What is the the library you have seen which more do a use more extensive of MARC21 ? 20:24 thd cait: just be careful that the code does not clobber your data :) 20:24 davi The library of Congress maybe? 20:24 cait yeah, I am, but so far it seems to be no problem 20:24 cait and it is standard compliant 20:24 thd davi: What do you mean by more extensive? 20:25 davi Using as much MARC fields 20:25 davi Some libraries use just a very small subset, you know 20:25 cait of 952 subfields or marc21 in general? 20:25 thd davi: LC is the largest library, however, OCLC would have the most diverse set of records. 20:26 davi both, as both are part of MARC21? 20:26 davi I think 9XX is part also 20:26 davi even if defined for local use only 20:26 cait hm I think you could argue about the 9xx fields 20:26 thd OCLC is a consortia, not a library of course. 20:26 cait and x9x , xx0 20:26 davi thanks thd 20:26 slef OCLC is a co-operative 20:26 thd s/consortia/union catalogue/ 20:27 thd as slef said 20:27 cait I think they are great differneces in libraries 20:27 jcamins davi: 9xx is not part of the MARC21 standard, because each library can choose a different meaning. 20:28 thd davi: I will try to restart discussions on *GPL on the mailing list tonight. 20:28 thd My computer had been fixed a week ago but I helped a couple of people move 20:28 davi jcamins, However 9xx use for "local use" is defined in the MARC21 standard, isn't it? 20:29 cait yes, but what fields and subfields you define, repeatable not repeatable is up to the library 20:29 jcamins Oh, you're saying that MARC21-compliant records can have 9xx fields? 20:29 davi thd, I think what we needed was just post draft of voting options (in wiki?) and then begin the review process in the mailing lists and so on, before beginning the voting? 20:29 jcamins Yes, of course. But the meaning of any of those fields is not standard. 20:29 thd davi: yes all of that 20:29 davi ack 20:30 cait for Germany the 9xx fields got divided between union catalogs, national library and some others 20:30 cait so I know which I can use safely and will not get problems with data interchange in Germany 20:30 davi jcamins, The meaning not, but the 9xx use yes 20:31 cait not sure if this is done somewhere else too 20:31 jcamins Yes, any field with a 9 in it (so, 9xx, x9x, or xx9) is local. 20:31 * gmcharlt says, pendantically, except the 490 ;) 20:31 thd davi: and I look to slef to supply one or more options for a vote to consensus process which allows revoting. 20:32 indradg folks... sorry to barge in in the 9xx discussion, but I was wondering what do I need to do to feed Koha from a custom book cover source (i.e. non-amazon / google / syndatics)? 20:32 jcamins gmcharlt: apologies. I'm still in denial. 20:33 * cait adds the $9 subfields 20:33 davi thd, Allow re-voting and editing vote and so on is a good more IMHO 20:33 cait not as exception, but as being local 20:33 jcamins indradg: at the moment, there's no easy way to do it, I don't think. 20:35 jcamins You can modify the XSLT stylesheet to include an <img>, if the cover images are named predictably. 20:35 indradg jcamins, just as I thought 20:35 Colin gmcharlt: did you see the other patch I sent a while back to get updatedatebase working? 20:36 gmcharlt Colin: yep - I can push it, although hope to hear results of your testing the patch for 4310 20:36 cait gmcharlt: so only patches for the acq blocker will get into 3.2 now? no other bug fixes? 20:36 jcamins I'm not sure exactly what you're trying to do, but if you just need to associate an image with each record, you can take a look at the image_library branch in my repository (http://github.com/jcamins/koha ). 20:36 gmcharlt cait: I'll do a final round of pushing *safe* bugfixes when I push the acq upgrade fixes 20:36 cait I have a lot of pending patches, just wondering :) 20:36 Colin First attempt failed - I'm restoring for a closer look 20:37 cait ah ok 20:37 thd gmcharlt: Yes, the XML meta-record wrapper is what should be done for holdings. 20:37 indradg jcamins, the case is this, my client - the principal govt library in my home state of West Bengal (india) is planning on a tie-up with local indian publishers for cover image syndication (nothing like this really exists for local (non-english) publications)... its not a Koha case yet, I'm trying to convince :) 20:37 cait safe as not changing templates or include database updates? 20:38 jcamins indradg: I see. In that case you'd need some sort of API, probably. 20:39 thd gmcharlt: I have a more radical idea of making MARC merely an import and export format with lossless conversion to and from a more granular XML format. 20:40 cait gmcharlt: I don't want to bug, just keeping track of my pending patches :) 20:40 gmcharlt thd: interesting idea - although the irony is that MARCXML, for the most part, *is* the most granular of the variousXML metadata formats 20:40 cait and working on one more to repair email notification of new serial issues 20:41 gmcharlt cait: no string changes; DB udpates may be OK, but criteria is that fix be obviously correct 20:41 cait ok, thx! 20:41 jcamins thd: that's pretty radical. 20:41 thd gmcharlt: I intend to extend the RDA enhanced XML schema whenever they have time to publish it 20:43 thd jcamins: there should be no nonsense such as numeric values in the same subfield as the units being designated and no language specific strings encoding information such as pagination. 20:43 jcamins It is a beautiful dream. 20:44 cait yes 20:44 jcamins I'm not quite sure how practical it is, but I certainly like the idea. 20:44 thd jcamins, gmcharlt: Everything which can be normalised should be so the automation systems can actually use the data and not wait for the humans to interpret the data :) 20:45 thd jcamins: RDA is built from such an XML format although less granular than what I describe. 20:45 cait thd: can we get rid of the isbd punctuaton too? 20:45 jcamins cait++ 20:45 Colin cait++ 20:46 thd cait: we will never be rid of it but we can relieve cataloguers of the need to create the punctuation. 20:46 jcamins thd: unfortunately, RDA is too expensive to be a viable standard. 20:46 jcamins At least, from my point of view it is. 20:47 cait In my dream world the system will take care of it, even stripping it from incoming data or tables like biblio and biblioitems 20:47 thd jcamins: I have been discussing a remedy for the cost with the publishers 20:47 Colin When UK libraries went from UKMARC to marc21 I wrote lots of complex code to put the punctuation in going "This is wrong" to anyone who would listen 20:47 jcamins Did anyone listen? 20:47 cait same here 20:48 cait the german exchange format does not include punctuation 20:48 Colin yes but they could only sympathize 20:48 cait but worldcat wants it and koha looks strange without 20:48 cait so they had to write that complex code too 20:48 thd jcamins: A free version of RDA will probably take a couple of years but the publishers are listening as is the president of W3C. 20:49 sekjal goodnight, #koha! 20:49 thd cait: Automation systems are responsible for creating ISBD publication in UNIMARC. 20:50 cait thd: sorry, i dont understand 20:50 thd s/publication/punctuation/ 20:50 cait ah 20:50 cait so UNIMARC uses isbd punctuation too? 20:50 cait or can use? 20:51 jcamins Well, let's hope that A) RDA turns out to be less of a disaster than it looks like coming down the pike and B) the high cost doesn't render it a lame duck before the publishers manage to make it affordable. 20:51 cait our horizon systems use unimarc without isbd punctuation 20:51 thd cait: UNIMARC defines the rules by which automation systems create ISBD publication. 20:51 thd s/publication/punctuation/ 20:51 thd :) 20:52 thd cait: MAB had been similar in some respects. 20:53 cait don't know MAB so well, Koha is the main reason I had to learn about bibliographic data formats 20:53 Colin gmcharlt: the 4310 fix does not work 20:54 thd cait: at the last MARBI meeting for the MARC 21 standard a proposal form DDB passed to set a fixed filed value designating that the record does not contain some ISBD punctuation and that consequently the automation system must supply the missing punctuation where needed. 20:54 cait ah yes 20:55 cait one of my coworkers was at the marbi meeting 20:56 cait I am still working on the hierarchies between titles... but I am very slow 20:56 thd cait: The MAB practise had still been to include much more ISBD punctuation than UNIMARC which leaves the problem to automation. 20:56 cait I m all for leave it to automation 20:56 cait but I am not so happy with the decision to not have isbd punctuation, because it's a terrible mix now 20:57 cait download a record from loc and you have punctuation, download one from another source, no isbd punctuation 20:58 thd cait: At the meeting, John Attig explained that leaving punctuation entirely to automation would be difficult to accomplish in MARC 21 where the user is editing the MARC record directly because MARC 21 did not have the advantage of arranging fields in ISBD order the way UNIMARC did. 21:00 cait hm. 21:00 thd cait: John Attig told me that the idea of having the cataloguer edit MARC records directly was an historical mistake which should never have been made. 21:00 jcamins _Now_ they tell us? 21:00 jcamins ;) 21:01 thd John Attig has been around long enough to know the history. 21:01 thd almost long enough 21:02 thd John Attig said that he was all for the idea of cataloguers using an easy to use interface where they would only need to know the tasks of cataloguing not fine details of a record exchange format. 21:05 jcamins That sounds wonderful. 21:05 thd If John Attig does not see an objection, automation systems implementers could probably accomplish the task without having it rejected. 21:05 jcamins But now it's quitting time, which means I get at least an hour of MARC-free time (i.e. my commute home). :) 21:06 jcamins Good night, #koha 21:06 cait :) 21:06 cait good night jcamins 21:06 thd jcamins: MARC 21 cannot be reformed sufficiently, but your system can. 21:06 cait and i have to accept that I will not be fixing this bug today :( 21:06 thd good night jcamins 21:06 cait bed time 21:06 cait sleep well #koha 21:07 * thd heads to the post office. 21:24 chris back 21:30 * richard reads the meeting notes 21:31 chris was a nice short and useful meeting i thought 21:31 richard yeah 21:36 * richard thanks natlib for sending the info about MARC format to the devel list 21:36 chris heh yeah 21:36 chris random eh 21:36 chris they sent one to me as well 21:37 chris i guess the only address they had for katipo was the devel list? 21:37 richard didn't think of that 21:37 richard but better it goes to the devel list than to individuals 21:37 chris yup 21:38 chris the good news, its mostly some zebra indexing changes, framework change, and xslt change and its done (to the basic level they are talking about anyway) 21:38 richard cool 21:53 chris http://patches.workbuffer.org/awaiting_qa/ 21:53 chris first batch 23:23 irma G'day #koha 23:25 irma Are you there Chris? 23:27 chris heya irma 23:30 * wasabi waves from kapiti 23:42 jcamins_a Were there really no messages on the Koha mailing lists today? 23:42 jcamins_a Or is there something wrong with my e-mail? 23:43 chris hmm i saw some 23:43 chris and one on koha-devel 23:43 chris jcamins: i count at least 5 to the main list 23:44 chris http://lists.katipo.co.nz/pipermail/koha/2010-September/thread.html 23:44 jcamins Hm. I guess either A) there's something wrong with my e-mail or B) someone downloaded all my e-mail. 23:45 chris that was me sorry 23:45 chris i read all your mail 23:45 chris :) 23:45 jcamins Heh. 23:46 jcamins Was there anything interesting? 23:46 chris i read so many peoples i cant keep it all straight ;) 23:46 chris shouldnt you be honeymooning somewhere? :) 23:47 jcamins I'm thinking there's a problem with my e-mail, since the webmail interface keeps on trying to download itself rather than display. Weird. 23:47 jcamins Shari's PhD classes started last Thursday, so no honeymoon this year. 23:47 jcamins Just homework. ;) 23:47 chris ahhh, that'd do it 23:47 jcamins Next year we'll have an actual reception and go on a honeymoon after. 23:48 chris so, what we need to do, is get kohacon in europe next year, and time your honeymoon to end as that starts :) 23:49 jcamins I like that idea! We'll be in Budapest until the very end of August. 23:50 chris ohhh 23:50 chris do we have any hungarian libraries i wonder 23:50 chris :) 23:50 jcamins So that might be a little early for Kohacon. 23:50 jcamins I don't know... I feel like CEU might use Koha, though. 23:51 chris well i figure if its northern hempishere, wont want to be end of october 23:51 chris that would be too cold 23:51 jcamins No, they use Millenium. 23:51 jcamins Good point. 23:51 chris maybe in the next month or so ill mail the list saying, now kohacon10 is nearly here, its time for people to start volunteering to organise/host kohacon11 23:53 jcamins We should have it in Helsinki... or Tallinn! then I can make a research trip across to Saint Petersburg afterwards. :) 23:54 chris there ya go 23:54 chris norway isnt far 23:54 chris and we definitely have norwegian libraries :) 23:54 chris and a norwegian support company 23:54 chris not sure about any in finland yet 23:54 jcamins Well, Norway sounds pretty great.