As this is my blog and I can do what I want with it, I’m using it for note taking.
Also follow the action at: http://www.nexpresslibrary.org/kohacon-09 (or search Twitter for kohacon09)
Having met Chris and Paul last night, I’m excited to hear them talk about the history of Koha, born 1999. Famous words, “It’s just a database, how hard can it be?” It’s the insane rules and exceptions that stole all his sleep. By 2002, BibLibre entered the scene. I wish we still had the IRC town hall meetings, those would be interesting to see (on IRC). The issue of ‘standards’ was an issue, so the French, English and others could use it. This is great – I love hearing the history. The English major in me is interested in the role press and FAQ writing played in promoting and supporting Koha. Kaitiaki – means? (Maori for ‘guardianship’) I’ll have to look it up. www.kohadocs.org and more press articles – all written by users and contributed to the project.
Community organization – Kaitiaki as the guardian, Release Manager to deal with new features of next stable version and Release Maintainer to deal with current version and patches (validate and commit) and Document Manager for kohadocs.org. Tried and failed to get QA Managers (hard and thankless)…needed, but have to handle rejection and conflict well, but not too well.
2005 – LibLime for local US support. Paul and Henri went into partnership. Koha 2.2 released. Fulltext searching and new http://www.koha.org. www.koha-community.org
It’s all about the community…boy wouldn’t kohacon2006 have been FUN!
Now onto 2007 and 3.0 (enter NExpress) with LibLime. Koha Days – one day a month, you work on features that no one is paying to fix. What a good idea! Also fix back-end problems and messes. Now too busy with paid work (so can NExpress ‘sponsor’ more Koha Days?).
2008 – koha 3.0, Dehli public library, Nichole worked on the Koha Manual, LibLime and BibLibre grew. Mason and Chris left LibLime, but Chris has been on sabatical for about a year. 3.0 a BIG change and 3.2 will be even BIGGER.
2009 – The present – Video! K’s helping Hand, Koha & SOPAC (BibLibre development) and today 🙂
Koha – a gift with strings – bring koha when you go to a friend’s house for dinner. Take, but expect to give back in the future.
More notes: http://dbouman.blogspot.com/ – Danny’s blog and LibLime’s blog. Chris picked PERL b/c his open source business already used it and there was a PERL library and MANY programmers. Programmers are a good kind of lazy – efficient!
SQL Structure and Koha Data Tables – Paul Poulain
- Parameters of Tables –
- Authorized values – use it freely to define lists that can be available in the program
- Branches – single locations, pieces of the overall Library
- Item Types – Circ rules go here (I love this, CE in French)
- Categories – the patron categories – we prefer Library City and Library Other and then Juvenile categories for both of those – very simple
- Biblios and Items Data – bulkmarcimport.pl can be updated to fit needs or use API for more complex needs. Joe Theolen recommends we look at MarcEdit to analyze bib data – I will follow up!
- UNIMARC v. MARC21 flavours – Koha has to deal with both efficiently. So:
- Koha stores raw MARC in a field (biblioitems.marcxml)
- Stores info in clearly named field (biblio.title, biblio.author, etc. and biblioitem.itemtype, etc.)
- Koha takes care of translating the MARC datas into biblio.* or biblioitems.* information
- The biblioitems table contains ALL representations of the title! (FRBR) – so Lord of the Rings are all stored in a single table, regardless of edition (I think is what he’s saying). 1 biblio, 1 biblioitem and multiple items (barcodes)
- biblioitems actually biblioedition – will this be reintroduced? FRBRizing stuff – complicated to not have 1 to 1 bib to edition relationship
- biblioitem table just a duplicate of the biblio table (could be merged, but noone has bothered)
- Which field is used:
- result lists and MARC detail – marcxml
- Standard bib detail result – marcxml if you have XSLT (and use marc 21) (unimarc libraries use bib/bibitems tables)
- Everywhere else (reserve list, issuing list) – biblio and biblioitems tables are used
- Items Data (all data stored in MYSQL) – biblioitems.marcxml and items table duplicate data
- When editing an item, you update 2 tables – items and biblioitems.marcxml
- Homebranch (owning library) v. holdingbranch (current location)
- itemcallnumber field – physical location = call number, home branch and shelving location
- Table/field names – borrower v. patron and issue v. checkout and our confusion with ITypes and their descriptions!
- onloan field – only filled when an item is checked out (used for z39.50 status info with Agent ILL)
- Primary Key – biblionumber and biblioitemnumber (in 3.0 – same number and the one in the URL)
- Primary Key in Items table – Item Number, not barcode table
- SQL Patrons – single table (called ‘borrowers’) – some say there is TOO much information in this single table.
- Fields change depending on the category chosen (no DOB on Institution category form).
- Borrowernumber – Koha primary key, so lost card = just update the record with a new barcode
- No ‘clear’ passwords – **** instead
- Only 1 barcode per user
- Check Out/Issues tables – borrowernumber, itemnumber, date_due and issuedate
Interested to hear what Diana found out in the |biblios.net for Catalogers session – Kathryn did a good job twittering the Square Peg/Round Hole OSS v. Proprietary ILS session. Lunch. hunger. food.