Don't forget that Koha let's you store item data anywhere you want to -- so long as you tell Koha where to find it by setting up your MARC to Koha links. At Nelsonville, we use a 9xx tag for all this data, but you could just as easily use 876 or 37, or any other (repeatable) tag. The choice belongs to the user, and is not controlled by Koha. Stephen Hedges Nelsonville Public Library
Sunday, April 25, 2004 16:11 CDT
Hi, Dave,
I can see what you mean about tags 876-878.
Most of the records I've seen here don't do anything towards keeping acquisitions data (which is a shame), but when they do they invariably avoid using the holdings data tags you recommend (from what I see, I wonder if NLC had a policy of using them only for serials) and instead have opted for the tag 37 (which is flexible enough to handle the important information and the limits of which encourage one to remember not to collude 2 or more different editions of works) or more frequently use a 5xx number (sometimes one not specifically allowed) to keep the information they want.
As library manager for a highschool library, I had to insist with my 'assistant' that such info not be encoded as a general public note (in 500) which is what someone had recommended to her prior to my appointment (not the kind of information we wanted highschool students to have: 'oh, this only cost $2.50, I can afford to lose it' problem).
The Athena system we were using already encoded data to an 852 (with unauthorised uses of various subfields, including a creative $w - we couldn't find any way to change these peculiarities) and so we used 37 (repeating for each copy as necessary, $n beginning with barcode to ID specific copy) for the additional data we wanted.
It would perhaps be good to recommend to users to adopt use of the 876-878 fields but still leave open the option of 37 for others. Smaller libraries, especially school ones, often don't have more than one copy of many works.
Could someone from development tell us where/how Koha is storing that more detailed acquisitions information and if it could be integrated into the MARC tag structure that Dave suggests in one of the near future releases?
Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, Manitoba, Canada
From: "Bigwood, David" <bigwood@lpi.usra.edu> Date: 2004/04/25 Sun PM 03:23:40 CDT To: <koha@lists.katipo.co.nz> Subject: RE: Re: [Koha] Export MARC from Koha
Fields 876-878 are a better choice to include acquisitions data. It includes the cost for each copy, different copies can have been purchased at different prices, or one could be a gift. It also includes where it was purchased, date acquired, item status and other subfields available for each copy.
Field 037 is repeatable but not linked to each copy in the same manner.
Sincerely, David Bigwood bigwood@lpi.usra.edu Lunar & Planetary Institute
Cataloging News http://www.catalogablog.blogspot.com
-----Original Message----- From: koha-admin@lists.katipo.co.nz [mailto:koha-admin@lists.katipo.co.nz]On Behalf Of Steve/Ollie/Steven F. Baljkas Sent: Friday, April 23, 2004 5:39 PM To: Chris Cormack; MJ Ray Cc: koha@lists.katipo.co.nz Subject: Re: Re: [Koha] Export MARC from Koha
Friday, April 23, 2004 17:30 CDT
Hi, Chris et al.,
Hi Guys
Theres also the budget data if using full acquisitions. This might be useful to export also.
Regarding the budget information kept in full acquisitions mode, I have to confess I haven't looked at that function, but there is a MARC tag available for item cost: tag 37.
I agree that budgetary info would be useful to
http://www.lpi.usra.edu/library/whats_new.shtml transfer, for a whole host of reasons (not the least of which is providing a base for determining replacement cost should an item be lost).
As for fines, maybe I am just (too) grateful
when things have been returned: rather than fussing about transferring fines, I'd suggest using the occasion of migration to offer an 'amnesty', something my local public library system does at irregular intervals (not dependent on system upgrades) and it seems to have a positive effect.
I don't know what is meant exactly by
'financial records' but I am assuming
that that is a euphemism for fines. Same as paragraph above.
I doubt that these can be exported in a useful way, but I could be wrong. Adding the ability to trigger code on fines to notify another accounting system may be interesting to someone.
Maybe if one adopted one of the neat ideas Dave Bigwood suggested (thanks Dave, I think what you suggested would be super) there would be some way of transferring the fine information (if substantial at least) to the patron file format? Anyway, just another two cents worth.
Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, Manitoba, Canada
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha