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

Install Meeting, 2005-07-05 21:00 +0000
by MJ Ray 16 Sep '05

16 Sep '05

Apologies for the late notice: I had trouble sending to this list last week. Tomorrow (Tuesday 5 July) at 21:00 +0000 (UTC), in #koha on irc.katipo.co.nz, there will be an IRC meeting to discuss installer and upgrader development for koha 2.3. All welcome. Possible topics: 1. General structure of the installer and upgrader; 2. auto-install features; 3. installer localisation (Locale::MakeText is in perl 5.8 core) Roughly the first 5 or 10 minutes will decide the timetable and I hope the meeting will be about an hour. If you can email any other topics or background reading links to this list beforehand, I'd appreciate it. -- MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/ http://www.ttllp.co.uk/koha/

5 4

Keeping Up
by Joshua Ferraro 09 Aug '05

09 Aug '05

Hi all, How do you keep up with library, technology and Koha news? What online resources do you use? What Lists, Forums, RSS feeds, Blogs, Wikis, podcasts, etc. do you use? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

3 2

Searching Group Meeting Notes
by Joshua Ferraro 09 Aug '05

09 Aug '05

Hi everyone, Sorry I'm late in putting this out: Present: kados slef owen chris paul thd rach This is just the highlights. If you want to grok the issues you'll need to read the log: http://koha.org/cgi-bin/logs.pl?recall=recall&saved_query=Searching%20Meeti… 1 Started with a discussion of Zebra: using zebra as a plugin isn't a good idea because we don't want to maintain two koha searching apis we need to test Zebra to determine which option is best: zebra for all (need to test .. does this make circ slower) or zebra for biblio, database for item info paul will begin working on porting Biblio.pm to reindex zebra (to store status info in the MARC record and re-index zebra during circ) chris will work on writing a wrapper for opac searches kados will begin working on configuration of Zebra thd mentioned some problematic UNIMARC issues related to compound fields 2 slef and kados discussed CQL as a query front end. discussion will be moved to koha-devel 3 the discussion turned to opensearch. kados showed the opensearch demo http://liblime.com/opensearchportal.html the idea of federated searching and ILL using opensearch was discussed slef suggested looking at RDF rather than RSS2.0 the discussion will be moved to koha-devel -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Koha ILS, Mambo Intranet, DiscrimiNet Filter jmf(a)liblime.com | Full Demos at http://liblime.com | 1(888)KohaILS

3 6

Authorities reporting to one tag only?
by Tümer Garip 08 Aug '05

08 Aug '05

I am using koha2.2.2b on a windows machine. It took me while to figure out how to work the authority file with MARC21 and may be I am still not very clear. I want to use an Authors authority table to report to MARC 100 field OR Marc 700 field That is if I am filling the 100 field (that field being set to be filled by authority table) searching for an author from the authority table and getting it works. However I cannot do the same with 700 field. This I believe is because the authority-file checks for ‘tag_to_report’ which can only be set to one tag only. Is this to mean that for each tag I have to recreate an authority table which does not sound logical as I will be just duplicating all the same data? Am I missing something here? Or is this what is ment to be? Tumer -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 20/07/2005

2 1

feature list for Koha 2.4/3.0 (hdl & paul coding planning)
by Paul POULAIN 05 Aug '05

05 Aug '05

Hi, Here is a list of features that hdl & me will code soon (reminder for thos who didn't follow : hdl & me are working together) All of them will be in next major version, some of them being backported to 2.2.x (that will be specified in this mail. when it's written "backported soon", it means that the backport will be done asap, as it's requested by one of my customers. otherwise, will be backported when hdl/me has time & if requested by someone) *1- Improved multi-branch support* =============================== Some of my libraries have more than one branch for circulation, borrowers, AND for acquisition, cataloguing... In Koha 2.2.x, all librarian have access to everything in a module (if they have the correct login). Some libraries need to have "budget X is for the branch AA", and "budget Y is for the branch BB" or "item must be created/modified only by the library that own them". So we will add the following features : 1-A BUDGET (BOOKFUND) ---------- A new row will be added to the budget, called "branchcode". If branchcode is '', then everybody can acquire using this budget. If branchcode is 'XX', then only a librarian from branch 'XX' can acquire using this budget. This will change : - the parameter >> bookfunds admin screen (adding the list) - the acqui-home.pl script : showing only bookfunds the user can use when placing an order. - in newbiblio, the librarian can choose the bookfund from the limited list. needs only a new row in aqbookfund table. will be in head & backported soon in 2.2.x 1-B SEPARATE BRANCH -------------- in some multi-branch libraries (like in NPL) the branch is only for members/circulation. All acquisition & cataloguing is done in a unique branch. In other multi-branch library, each branch has it's own cataloguing, acquisition... team. So, we need a support for those libraries. I propose to have a new systempreference entry, called "IndependantBranches" (native english, feel free to suggest something better) When not set, the behaviour is as in 2.2.x When set, the behaviour becomes : * in acquisition module, only suggestions made by a user from the same branch as the librarian can be accepted/rejected. * in acquisition module, an order can be modified/recieved/closed only by a librarian from the same branch than the librarian that created the basket. * in catalogue module, an item can be modified/deleted/created only by a librarian from the same branch as item owner branch * in members module, a member can be created/modified only by a librarian from the branch of the member. don't need a change in DB, will be in head & backported soon in 2.2.x *2- OTHER IMPROVEMENTS* ========================== 2-C tracking who does what Koha will save which librarian creates/modify a biblio, and when (but not what he changed ? open question here, as saving what he changed can be very complex) Needs a new table in DB, will be in head only. 2-D late orders in acquisitions, create a new page to see, for a given bookseller the order lines that are still not recieved (+ nice printing of this "late recieve" list using doNotPrint css rule). The page will be like bull/lateissues.pl where you can select a bookseller & see the late serial issues he has. the list will show order info, including basket #, order date,...) No change in DB, will be in head, backported asap in 2.2.x 2-E serial note serials management : add a row to the serial table, for librarian notes (like "phone call to the bookseller on 06/25, should arrive in 10 days") needs a new row in DB. Will be in head, backported in 2.2.x 2-F bookseller history tracker A tool to follow revivals history (in acquisition & in serials module). When you claim a bookseller for a late book or serial, the claim will be stored in an history table. Will be in head, not completly analyzed yet, feel free to suggest how to do this & what to do exactly. 2-G mail contact Adding a "mail contact" in branches table. this mail will be shown in various places (in OPAC for example) and used on some periodic jobs. Needs a row in branches table. Will be in head, backported in 2.2.x 2-H "circulation list" in serials (subscription creation), the librarian will be able to select some users that will recieve the serial issue once after each other. this list will be printed by the librarian when recieving an issue. (then fasten the printed list to the issue, and make it circulate between users). The "reader list" can be ordered by the librarian. In OPAC, users can subscribe & unsubscribe to any "subscription circulation list". A systempref (CirculationList) will activate or un-activate this feature (the OPAC sub/unsub one). will be in head. 2-I "serial issue alert" With this feature, in serials, a user can subscribe the "issue alert". For every issue arrived/missing, a mail is sent to all subscribers of this list. The mail warns the user that the issue is arrive or missing. Will be in head. 2-J return date calculation For instance, the return date does not rely on the borrower expiration date. A systempref will be added in Koha, to modify return date calculation schema : * ReturnBeforeExpiry = yes => return date can't be after expiry date * ReturnBeforeExpiry = no => return date can be after expiry date will be in head & backported soon in 2.2.x -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

6 10

Translation
by Joshua Ferraro 04 Aug '05

04 Aug '05

Hi all, OK ... this one's for the Web Site group and the Documentation Group. In bug 953, MJ requests that we setup a better translator's page complete with links to the latest .po files. Here's an example: http://audacity.sourceforge.net/community/translation Paul then pointed me to his site which is running on Kartouche, a communal translation tool: http://bureau.paulpoulain.com/kartouche/ Given the fact that many translators aren't going to be very tech savvy, I think we should make Koha translation web-based. That is, we should have a site where translators can go, setup a login, assign themselves a translation project, run the .po to get the English, and insert their language in text fields hitting submit when they are done ... so paul, can Kartouche facilitate this? Is there another software app that can? -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Koha ILS, Mambo Intranet, DiscrimiNet Filter jmf(a)liblime.com | Full Demos at http://liblime.com | 1(888)KohaILS

5 9

opac-user & opac-userdetail
by Paul POULAIN 02 Aug '05

02 Aug '05

Hi, in opac, there is opac-user & opac-userdetail perl scripts. They seem to be highly similar, except that opac-user has more informations it seems (current reserves & history, fines & debts) Note that opac-userdetail don't work in css templates, as opac-userdetails.tmpl is undefined. BUT : NPL uses opac-userdetail.pl & has a .tmpl so, should we drop opac-userdetail & use opac-user or did I miss something ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1

Acquisitions Group Meeting
by Joshua Ferraro 01 Aug '05

01 Aug '05

Hi all, I spoke with HDL today on IRC about Koha's Acquisitions. There are a few concerns: Short-term: 1. Koha's current Acquisitions modules appear to be broken (HDL can expand on this) 2. Koha's simple acquisitions is too simple (does not include budget management for instance) Long-term: 3. Koha should support standards for Acquisitions like EDI, WDDL, SOAP or Web Services. I propose that we discuss fixing Koha's current solutions for the 2.2.x series and also discuss the long-term solution that we hope will be in 3.0 if we can find a sponsor for the development. So who has a vested interest in Koha's Acquisitions asside from HDL and myself? What ideas do you have? When we get some responses we can decide on a meeting time and I'll put together an agenda. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

3 2

about PROG templates
by Paul POULAIN 30 Jul '05

30 Jul '05

Hi owen & al, I saw your commits on HEAD about PROG templates. they are far from complete (or i missed something). Do you have a timesheet to complete them ? For instance, I still work on default, but once you say prog are ready, i'll swap to them as decided. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1

MARC Holdings, Koha, and Migration
by Thomas D 28 Jul '05

28 Jul '05

Things that you were afraid to ask about for MARC holdings and why it mostly does not matter yet for Koha, with a MARC 21 holdings mapping supplement. UNIMARC and MARC 21 holdings are considered below in a rather tedious manner. A mapping of common standard MARC 21 subfields to a single local use field for linking to the Koha items table is presented in the last section for migration purposes. Please comment and offer corrections, etc., especially about the migration mapping. Even if you would ignore the tedium of the previous sections, please comment about the migration mapping if you have an interest in migration issues for Koha. I have not tested this mapping in an actual implementation and may even be mapping MARC 21 to orphaned columns in the items table. If the migration mapping may be useful, it should form part of a migration how-to document. STATEMENT OF REASSURANCE Let me state at the outset, that I am satisfied that the current limitation for linking the Koha items table to one and only one MARC field is not a problem restricting Koha from functioning in any important way for its current likely users. Development resources should be concentrated elsewhere. At some suitable point in the future, it would be appropriate to revisit this issue. I have brought this issue forward previously with a less complete understanding of how and why Koha holdings works the way that it does. CURRENT KOHA HOLDINGS MODEL Koha has adopted a holdings implementation modelled on the French Recommendation 995, http://www.adbdp.asso.fr/outils/infogestion/r995.htm . Using this model, holdings information for one record is retained in one and only one local use field. Using Koha with MARC 21, any single field may be adapted for that purpose. 952 is the Koha default implemented at NPL. UNIMARC HOLDINGS UNIMARC had omitted holdings support from the bibliographic format. Implementers used local use fields or some other means for holdings information. The French government supported recommendation 995 for public libraries. The IFLA recently approved a UNIMARC holdings format as a separate record from the linked bibliographic record, http://www.ifla.org/VI/8/projects/UNIMARC-HoldingsFormat04.pdf . Paul Poulain reports the UNIMARC holdings format as not yet adopted by any ILS that he knows. Related bibliographic control number 004 in UNIMARC holdings identifies the control number 001 for the corresponding UNIMARC bibliographic record on the same system. Other system control number 035 in UNIMARC holdings matches 035 in UNIMARC bibliographic on the same system for identifying the control number 001 for a bibliographic record obtained from another system. In accordance with the approval of the UNIMARC holdings format, two fields are being added to the UNMARC bibliographic format. Location and call number 852 is being added to UNIMARC bibliographic to match the corresponding 252 field in UNIMARC holdings. Electronic location and access 856 is being added to UNIMARC bibliographic to match the corresponding 252 field in UNIMARC holdings. Within UNIMARC holdings, copy number $t is the linking subfield for identifying the particular copy across multiple fields. UNIMARC SERIALS HOLDINGS The UNIMARC holdings format allows storing complex serials holdings information in a format that is easy for machines to parse, although, difficult for humans to read. Display presentation and complementary textual holdings fields allow for easy human readability of complex serials holdings. Complex serials holdings can be stored in the following fields. aptions and patterns fields 500-502 are optional. Enumeration and chronology - basic bibliographic unit 510 is mandatory if applicable. The other enumeration and chronology fields 511 and 512 are optional. The simpler textual holdings fields 520-521 are optional. 500-502, 510-512, and 520-521 are linked together by interfield linking data $6. Recommendation 995 only allows for simpler format textual holdings that are easy for humans to read but difficult for machines to parse. At some future time, when Koha needs to support more complex needs of academic libraries or other libraries with complex serials holdings, to provide for the configuration of OpenURL resolvers this issue should be addressed. MARC 21 HOLDINGS MARC 21 bibliographic has always provided multiple holdings fields. MARC 21 holdings format for storing holdings information in a separate record linked to the bibliographic record has become more popular in recent years. Despite the holding standard for MARC 21, some systems have implemented nonstandard local use holdings fields and subfields. Certainly, some information often not considered to apply well to standard holdings fields or not provided in the standard at all requires local use field or subfield implementation. Koha's use of a local use field for holdings is certainly not exceptional. At the beginning of the year, OCLC announced their plan to implement holdings in separate holdings format records by year's end. In the the MARC 21 bibliographic format, as in the MARC 21 holdings, format, copy number $t is the linking subfield for identifying the particular copy across multiple holdings fields. For those cases where a subset of the copy is required, materials specified $3 is the linking subfield for identifying the subset. Control number for related bibliographic record 004 in MARC 21 holdings identifies the control number 001 for the corresponding MARC 21 bibliographic record on the same system. System control number 035 in MARC 21 holdings matches 035 in MARC 21 bibliographic on the same system for identifying the control number 001 for a bibliographic record obtained from another system. MARC 21 SERIALS HOLDINGS MARC 21 holdings fields from both MARC 21 bibliographic records and MARC 21 holdings records allow storing complex serials holdings information in a format that is easy for machines to parse, although, difficult for humans to read. Display presentation and complementary textual holdings fields allow for easy human readability of complex serials holdings. Complex serials holdings can be stored in the following fields. Captions and patterns fields 853-855. Enumeration and chronology fields 863-865. The simpler textual holdings fields 866-868. 853-855, 863-865, 866-868, and item information fields 876-878 are linked together by field link and sequence number $8. If the enumeration and chronology fields 863-865 are not used, then location 852 or textual holdings fields 866-868 are linked to item information fields 876-878 by $3. The all holdings in one local use field model that Koha uses based on Recommendation 995 only allows for simpler format textual holdings that are easy for humans to read but difficult for machines to parse. At some future time, when Koha needs to support more complex needs, of academic libraries or other libraries with complex serials holdings, to provide for the configuration of OpenURL resolvers this issue should be addressed. DEVELOPMENT OF KOHA HOLDINGS MODEL An account of the development of the Koha holdings model can be found in the "Koha diary" along with much other useful history. Hedges, Stephen. A Koha diary : implementing Koha at the Nelsonville Public Library. kohadocs.org. 2005. http://www.kohadocs.org/koha_diary.html . The diary describes part of how the default Koha table linkings to MARC fields had originated. Poulain, Paul. Re--dumpmarc : date--Wednesday May 21, 2003, 10:02 AM ; to--shedges / from--paul.p. Stephen is quoted. "We've been discussing our item information. There is _so_ much valuable information in our old system about each item that we don't want to lose, but which doesn't fit into a MARC tag. Things such as date last seen (which is also in Koha items table) or date last borrowed (also in Koha). We're very tempted to just write a script to read the item information from our old system and load it directly into the Koha items table." Paul replied. "Why don't you add specific non-standard marc tags in the parameters table and map them to the corresponding koha fields ? Note that I agree to say that there are only a few 852 subfields code that are free in MARC21 (1,4,5,7,9,d,o,u,v,w,y if my table is right), but it may be enough." Local use field 952 had been used for holdings by the ILS that NPL had been using prior to migrating to Koha and was retained for the Koha to MARC items linkings and presented as a default for Koha. The substitution of a local use field avoids the risk of some possible future assignment of unassigned subfields for those items table columns that are not part of the MARC standard. MARC 21 TO KOHA HOLDINGS MAPPINGS Mapping existing standard data to a MARC 21 local use field is necessary when migrating holdings to Koha. If using the default local use field 952, the following may be a common mapping. Be sure to construct unique $952 fields populated from the corresponding $t. Mappings with multiple subfields listed should have all listed subfields mapped to the corresponding local use 952 subfield where the last populated subfield value would overwrite any previous populated value for that local use 952 subfield. Map 852 $t, 876 $t, 877 $t, and 878 $t to 952 $t for items.copynumber. (If you have been using $3, you should find some way of combining $t with $3 to form a unique whole number.) Map 852 $p, 876 $p, 877 $p, and 878 $p to 952 $p for items.barcode. Map 541 $d; or 876 $d, 877 $d, and 878 $d to 952 $d for items.dateaccessioned. Map 850 $a, 852 $a, or 852 $b to 952 $b for items.homebranch. Be sure to convert to the 4 character all caps code as defined for Koha branches. Map 541 $h; or 876 $c, 877 $c, and 878 $c to 952 $o for items.price. Map 365 $b; or 876 $c, 877 $c, and 878 $c to 952 $r for items.replacementprice. Map 852 $b to 952 $d for items.holdingbranch. Be sure to convert to the 4 character all caps code as defined for Koha branches. Map 506 $a, 876 $h, 877 $h, and 878 $h to 952 $y for items.notforloan. Be sure to convert to an integer boolean. Map 876 $j, 877 $j, and 878 $j to 952 $1 for items.itemlost. Be sure to convert to an integer boolean. Map 876 $j, 877 $j, and 878 $j to 952 $w for items.withdrawn. Be sure to convert to an integer boolean. Map 852 $k, 852 $h, 852 $i, and 852 $m concatenated together sequentially to 952 $h for items.itemcall number. Map 506 $a, 876 $j, 877 $j, and 878 $j to 952 $4 for items.restricted. Be sure to convert to an integer boolean. Map 852 $c, 856 $u, 876 $l. 877 $l, and 878 $l to 952 $c for items.location. Migrating MARC 21 holdings to Koha would certainly be easier if Koha supported multiple fields for holdings. However, as stated above, that is an issue best left for a future time. Thomas D --------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com

1 0