Liz Rea thank you! That is also likely to be the answer to another problem (first raised on this list in December by Zico) of ‘status’ not displaying on systems upgraded from early versions. I’ll check that out as soon as .... Bob Birchall CALYX ________________________________________ From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Liz Rea Sent: Tuesday, 16 February 2010 6:05 AM To: Mike Mason Cc: Koha@lists.katipo.co.nz Subject: Re: [Koha] How make item availability accessible via Z39.50? A while back, we asked a similar question of our LibLime support folks. Here is what they told us: Here are the basic rules for  determining availability in Koha:  There is no single subfield indicating item availability.  All checked-out items have a date in subfield $q.  if there is no date in subfield $q then you must check subfields $0, $1, $4  and $7. If these four subfields all contain a 0, the item is available. I hope this helps you out. :) Liz Rea NEKLS On Feb 15, 2010, at 4:58 AM, Mike Mason wrote: Hi all I'm a newbie configuring Koha (Liblime's Koha Express [release 3.00.02.012]) for the first time. Our library is part of a consortium of theological libraries that has a virtual union catalogue -- an OCLC site running Zportal -- a Z39.50 client that queries multiple servers similtaneously.  So I have to give the folks at OCLC info about how Koha stores data on Holdings in tag 952 so they can configure their Zportal to look for it.  I want the Z39.50 search result to show whether an item is AVAILABLE. Koha shows this in its own OPAC, but how can an external Z39.50 client find it? Is it in a MARC field/subfield? Our Liblime trainer suggested 952$q, but when I test this with Bookwhere, nothing is returned. Anyway, 952$q is 'checked out', and to be available, an item would have to be not only not checked out, but also not lost, not withdrawn etc.  Is availability stored in a mysterious Koha variable like biblioitem.available? (No such variable is listed in the Koha to Marc mapping table, as far as I can see). If it's a Koha variable not mapped into MARC, how can Zportal get to it?  It seems to manage with other ILS packages. Excuse my vast ignorance of library matters; I'm not even a librarian; kind of honorary computer support person.  I've had to learn more about MARC than I ever wanted to know, and I hate it already. Mike Mason Cordially, Michael Mason (Rev. Dr.) Michael Mason Librarian & Director of I.T. Redemptorist Seminary Library 10 Majella Ct. Kew, Vic. 3101 Phone: +61 3 9817 9758 Fax:     +61 3 9816 9805 Email: M.Mason@ytu.edu.au _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

Hi, On Feb 15, 2010, at 9:49 PM, Mike Mason wrote:

thanks for that info. It makes sense: $0 is for Withdrawn, $1 Lost, $4 Damaged, $7 Not for loan. Would all of these have to have "authorised values" of 0 and 1 set up in them?

Yes, although sometimes there can be more than one authorized value for a given field. For example, out of the box in 3.2 alpha, there are five values defined for lost: 0 - not lost 1 - lost 2 - long overdue (lost) 3 - lost and paid for 4 - missing For the purpose of testing the items availability, 0 in one of those subfields means that the condition does not apply, while a value greater than 0 means that the condition does apply.

I wonder what is in $q if no date is there: 0 or blank?

Nothing - subfield $q is omitted if the item is not on loan.

Do you or anyone else out there know how an external Z39.50 client could be programmed to automatically check that there is no date in 952$q and that the other 4 subfields are 0, in order to establish availability?

I can't speak to the general case, although I image OCLC is capable of tweaking ZPortal to deal with Koha's method of expressing item status.

Sounds as if Koha should do this itself, and have a simple "Available/Not available" variable accessible to outside Z39.50 clients. I'll put it into Bugzilla.

Many librarians gave their lives serving on the DLF ILS-DI task force debating the question of how to communicate item availability between ILSs and discovery systems. I bow my head in their memory. OK, not really, but it sometimes felt that way. :) It's a surprisingly difficult question given the number of edge cases. For example, does availability mean available for loan, available to look at in the library, available to place a hold request on, available for ILL of photocopies, etc. Nonetheless, I think you have a good idea, and I look forward to the bug report. A heuristic for populating a single subfield that expresses yes/no item availability, although it will be imperfect in the general case, is better than nothing when contributing records to a service or consortium that doesn't want to or can't deal with five different item status subfields. Regards, Galen -- Galen Charlton VP, Data Services Equinox Software, Inc. / The Evergreen Experts email: gmc@esilibrary.com direct: +1 352-215-7548 skype: gmcharlt web: http://www.esilibrary.com/ Please join us for the Evergreen 2010 International Conference! It is being held April 20 - 23, 2010 at the Amway Grand Hotel and Convention Center, Grand Rapids, Michigan. http://www.evergreen2010.org/