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

RDA and Koha - where we are and HOW do we get ready
by dschust1＠tx.rr.com 05 Nov '10

05 Nov '10

The final report for RDA will be out in the spring and RDA records are already being created and loaded into OCLC that Koha libraries are trying to use. Library of Congress will most likely adopt and start cataloging next year in RDA format - my personal suspicion. FRBR has been out for 10 years and WE(librarians) have not made much of a concerted effort to make that work I believe because we(librarians) didn’t know what RDA was going to do. This might be a project that we all(librarians and programmers) need to figure out what needs to be done - create a committee and spec out the work and we all pay to have the work done. What I hear from vendors is Until LIBRARIANS can tell the vendor what the LIBRARIANS/USERS WANT/NEED vendors don't know where to begin. There is a LOT of coding that needs to be done not only for bibliographic items but for Authorities to work right not to mention the RDA changes to Authorities. I've seen lots of discussion around Authority work and I would hate to see a library do authority programming NOT based on RDA specs at this point. Joy M. Banks Catalog Librarian came up with these starting points for Koha and RDA - The system needs to be able to uniformly display both the GMDs that are in current AACR2 records and the new 3xx fields that RDA would implement to replace GMDs (this is a big one since I don’t know about anyone else, but we have no intention of going back to update all of our AACR2 records to RDA) - The system needs to take into account a new FRBR model that will both serve the needs of patrons who wish to find every manifestation of a particular work and also those who wish to see specific manifestations - The system needs to be able to perform global updating for authorities so that changes made to authority records will be automatically applied to the bibliographic records to which they are attached - Any development with authorities and display also needs to take into account what will soon be a proliferation of $e’s in 1xx and 7xx fields (this one is fuzzier for me… I’m not quite sure if I’ve captured this change). These subfields should only affect the bibliographic records, not the authorized forms of the headings. She also suggested this: Mac Elrod has developed a kind of cheat sheet (http://slc.bc.ca/cheats/aacr22rda.htm) that highlights some of the major RDA changes. It’s from September, but at least it’s something that we can consider. So where do we start and begin working on this? I believe Ian touched the tip of the iceberg during KohaCon10 in this regard. I'd love to start the dialog and see where it NEEDS to go. David Schuster Plano ISD

2 1

Oracle nerfs MySQL, calls it MySQL classic, and charges $2, 000+ for features like InnoDB
by Kyle Hall 04 Nov '10

04 Nov '10

http://www.mysql.com/products/ <http://www.mysql.com/products/>I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres? Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org )

4 9

bugzilla question
by Marcel de Rooy 04 Nov '10

04 Nov '10

Hi, Couldn't find this on the wiki. Should I leave a bug on resolved/fixed, resolved/invalid etc. or should they always go to closed in the end? Just some number: resolved+fixed=2636 bugs. Closed/fixed= only 78. Regards, Marcel

2 1

itemBarcodeInputFilter or Client side JS?
by Koustubha Kale 03 Nov '10

03 Nov '10

Hi All, We are implementing Koha at a college. They have a existing software for library. They have barcoded all their collection of about 150000 books with this software. The peculiar thing about the software and the barcode it generates is this : The barcode related data stored in the database of the software backend ( MS SQL) is the item's accession number & item type. The actual barcode is not stored anywhere. The printed barcodes are like this B011364, B011436, AR011346, AR011436,AR018100,AR018103,AR018104,AR018105. ( Note the duplicate accession numbers) The first alphabets correspond to the itemtype code stored in a table. The remaining numbers are the accession number stored in a table without the leading zeros. This causes a problem while migrating this data to Koha due to the missing leading zeros and arbitrary length of the string and the fact that accession numbers are same for different item types. While generating a barcode for a new item the software takes the itemtype and the accession number and prints out a barcode label in the required format. When the barcode is read back in the softwares circulation module by a barcode reader, a asp script on the server separates the item type and the accession number, strips the leading zeros from the numeric part and does a search on the database by means of a join on the two tables. As the college has stuck these barcode labels on all items, we have to figure out how to emulate this functionality in Koha. (Post migration we will generate & print barcodes from Koha; so we dont have to emulate this logic in the barcode generation for Koha). I was thinking we could store the barcode in Koha as itemtype-accession_number ( without the leading zeros e.g. AR-18100) retrieved from the old softwares database and when reading it in circulation in Koha we convert the barcode from for example AR018100 to AR-18100. I see two options to acchieve this.. options : 1) Create another filter for itemBarcodeInputFilter and modify the sub barcodedecode in C4/Circulation.pm 2) write a client side javascript to do it. I would like to know is 1) What is the better way to acchive this? 2) Is there way for us to avoid a patch to Koha which will probably be useless to anybody not migrating from this particular software. By using opacuserjs perhaps.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

4 6

Classification Sources
by Cybermon 03 Nov '10

03 Nov '10

Dear Koha team, Can I use two classification sources for cataloging of Koha. For example, both of DDC and LCC. Sorry I could not find the BBK Classification of Russian in Koha. Please someone help about it. Gana

2 1

Getting rid of YUI ?
by Paul Poulain 02 Nov '10

02 Nov '10

Hi world, As you know, we are using both YUI and jquery javascript libraries in Koha. That's too much ! I think jquiry-ui (http://jqueryui.com) is good enough to decide to get rid of YUI. Pro: * jquery much more developed * yui & webdev have problems working together * a lot of informations are available for jquery, including tutorials and books * http://jqueryui.com/docs/Theming/API seems much more clear & easy to use to me than yui css (is it just me ?) * jqueryui comes with (a themable) complete set of icons Cons: ? (Anyone want to argue ?) So, I propose the following roadmap : * new templates should be developed using jquery, not yui * 3.4 would still have both * in 3.6, we get rid of yui Other question : should we have jquery code inside koha (and thus having to take care of the updates) or should we use an external source ? (does this exist ? for yui it does, see yuipath syspref in koha) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

8 8

Re: [Koha-devel] wiki [important] changes & request for reviewing
by MJ Ray 02 Nov '10

02 Nov '10

Paul Poulain wrote: > - http://wiki.koha-community.org/wiki/Category:Abandoned_RFC => contains > abandoned rfcs (because it's no more relevant or we have lost contact > with the developer) I've rescued two of them (multi-level biblios and requiring items) which I'd still like to see in 3.4 although I have no funding for them at the moment. > on page : http://wiki.koha-community.org/wiki/Category:RFCs there are > still 19 pages that I don't know what to do with. > > FOLLOW-UP => ANYONE who has entered a RFCs on the wiki should go and > double-check that it's at the right place. On some RFCs, the author was > displayed in the RFC itself (BibLibre or Liblime most of the time, but a > few others), but the edition history has been lost when we moved the > wiki. So, for many RFCs, there is no information in the RFC itself and > it seems to have been filed by nengard, which is wrong. Why didn't you ask? I have a copy of what I think is the edit history, although the move also disrupted it by renaming many pages. Here is a list of RFC creator usernames from the old wiki: rfcs3.2:rfc32_hourly_circ gmc created rfcs3.2:rfc32_email_checkout_slips gmc created rfcs3.2:rfc32_fine_thresholds gmc created rfcs3.2:rfc32_opening_hours gmc created rfcs3.2:rfc32_recalls gmc created rfcs3.2:rfc32_holdability_flag gmc created rfcs3.2:rfc32_notifications_and_opac_messaging gmc created rfcs3.2:rfc32_system_groups gmc created rfcs3.2:rfc32_marcstructure_translation eric.begin created rfcs3.2:rfc32_description_translation eric.begin created rfcs3.2:rfc32_readingrecordhistory tipaul created reading record management by patron rfcs3.2:acq-permissions nicomo created rfcs3.2:create-item-when-ordering nicomo created rfcs3.2:enhance-closing-basket nicomo created rfcs3.2:refining-budgets nicomo created rfcs3.2:better-stats-about-acq nicomo created rfcs3.2:refining-budgets-management nicomo created rfcs3.2:bib-search-acq nicomo created rfcs3.2:searches-on-orders nicomo created rfcs3.2:suggestion-opac-searchtest nicomo created rfcs3.2:suggestion-opac-hold nicomo created rfcs3.2:suggestion-staff-workflow nicomo created rfcs3.2:pqf_search tipaul created rfcs3.2:display_item tipaul created : RFC for displaying items in large networks rfcs3.2:rfc32_koha_api_uml_diagrams_and_e-r_diagrams tajoli created rfcs3.2:rfc32_guided_reports tipaul created guided reports improved rfcs3.2:rfc32_turn_on_warnings gmc created rfcs3.2:rfc32_general_holds_improvement gmc created rfcs3.2:rfc32_hold_request_targeting gmc created rfcs3.2:rfc32_ajax_in_the_staff_interface pianohacker created rfcs3.2:rfc32_advancedpatronsearch danny.bouman created RFC for advanced patron search rfcs3.2:buying-analysis tipaul created rfcs3.2:rfc32_cas_compatibility nicomo created rfcs3.2:rfc32_unsaved_changes_notification danny.bouman created rfcs3.2:advanced_cataloging_search danny.bouman created rfcs3.2:rfc32_fast_add danny.bouman created rfcs3.2:rfc32_syndetics_support danny.bouman created rfcs3.2:rfc32_place_hold_multiple_items danny.bouman created rfcs3.2:rfc32_tag_multiple_items danny.bouman created rfcs3.2:rfc32_holdings_structure gmc created rfcs3.2:authority_control_improvements gmc created rfcs3.2:rfc32_brief_records gmc created rfcs3.2:improved_batch_capabilities danny.bouman created rfcs3.2:rfc32_improved_permissions danny.bouman created rfcs3.2:rfc32_staff_place_hold_opac danny.bouman created rfcs3.2:rfc32_import_export_system_preferences danny.bouman created rfcs3.2:rfc32_barcode_prefixes rch created rfcs3.2:rfc32_multiple_opac rch created rfcs3.2:rfc32_take_items_out_of_bib gmc created rfcs3.2:storequeries hdl created rfcs3.2:rfc32_improved_security pustake created rfcs3.2:rfc32_item_level_itemtypes rch created rfcs3.2:blocking_non_blocking_rules tipaul created rfcs3.2:fines_in_days tipaul created rfcs3.2:dbix-class amoore created rfcs3.2:rfc32_biblio_table rch created rfcs3.2:rfc32_subtitle_field mdhafen created rfcs3.2:requiring_items mjr created rfcs3.2:rfc32_circ_policies rch created rfcs3.2:rfc32_patronselfprivacy tipaul created : RFC for patron dealing with their Reading History at OPAC If any appear multiple times, I think the later ones are translations. Perhaps someone could recover any RFCs that they think are/should not be abandoned, based on that list? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work http://www.software.coop/products/

2 1

Template for RFCs updated
by Paul Poulain 02 Nov '10

02 Nov '10

Hello, it's a follow-up of my yesterday mail about the wiki RFC template: i've updated the template for RFC. Now, you can/must also enter the bugzilla number, like this : |bug=<bugzillanumber> The number will be transformed into a nice url to the bug itself, just enter the number (|bug=5420) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

RFCs for 3.4 from BibLibre (serials & acquisitions)
by Paul Poulain 02 Nov '10

02 Nov '10

Hello, I have filed RFCs for all enhancements you can expect from BibLibre in the next few months. All of them are sponsored (by Saint-Etienne University), and will have to be delivered to the library for a "go live" in May-2011 * You can find them on the wiki (search biblibre rfc for3.4) : http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir… <http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir…> * You can also find them on bugzilla : i've added a saved search, shared with everybody, called "Koha 3.4 enhancements". They are only related to serials and acquisitions. What's the next step ? * read the RFCs * comment them (on the wiki or on bugzilla) * we will probably propose/organise an IRC meeting to discuss & get any feedback for all those incoming developments. None of them (except the solR one) has started, so if you want to give us an advice, add something, ... it's now or it may be too late ;-) <http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir…> -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Changing default koha mapping 440$a -> 490$a
by Robin Sheat 01 Nov '10

01 Nov '10

In 2008, the 440 MARC field was obsoleted[0], and 490$a is the equivalent. Default Koha installs (unless it was updated relatively recently) map 'seriestitle' to 440$a. I'm planning to update this to 490$a for a client's install, but was wondering: a) is this likely to make things blow up in unexpected ways?, and b) is this worth putting into the default Koha mapping so that new installs have it set up correctly? For obvious reasons of not messing with peoples' data, adding this as a database update is probably a bad idea, but is there any issue with having it as the new default? [0] http://www.loc.gov/marc/bibliographic/bd4xx.html -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

2 1