Steven, Most of this I agree with 100%. Well said, it diserves better distribution. However putting copy information into 037 is not the way I'd go. It is not easy to distinguish the different information for different copies there. Also, if we take a FRBR approach 037 seems to apply to the expression but acquisition information belongs at the item level. Field 876 seems a better choice. That would tie the donated copy from 1999 to one item and the 1998 copy costing 45.00 from a particular fund with another copy. Sincerely, David Bigwood bigwood@lpi.usra.edu Lunar & Planetary Institute -----Original Message----- From: baljkas@mb.sympatico.ca [mailto:baljkas@mb.sympatico.ca] Sent: Thursday, July 24, 2003 7:51 PM To: larry@larrystamm.com; koha Cc: baljkas@mb.sympatico.ca Subject: Re:[Koha] data import question - a few more thoughts Thursday, July 24, 2003 18:46 CDT Hi, Larry, Glad that some of what I wrote was useful. I know that the MARC stuff isn't easy for those who haven't been 'initiated' into its mysteries. I snipped back some of my verbiage to make the more important parts a little more identifiable. Yes, your understanding is correct, Larry, in that 852 is "mainly" for use within an organization. However (you knew this was coming, didn't you? ;-) ) ... Part of the whole purpose of creating MARC records was the sharing of cataloguing data. LC proves this daily by giving us all free access to its records (well, one has to have the Internet, etc., etc., but that's not their fault). Part of what we're supposed to be doing, as cataloguers, is obey the conventions (AACR2R, ISBD, etc.) and the standards for use of the MARC21 system (this is why we are given examples, and for those lucky enough to work in libraries that can afford such, access to the Library of Congress Rule Interpretations, LCRIs). If sharing is going to be possible, we do have to look at how things are set up. Yes, it was arbitrary (small groups of people working mainly at LC), but it is thorough. It isn't really a good idea to start switching things around. I remember Athena very well. Especially the arguments I had with my so-called assistant over the useless entry of data like source of acquisition date, fund, price, all of which can be entered in other MARC fields properly kept out of patron's prying eyes anyway (no, I know that data isn't useless, but it can be very frustrating to try explaining to a patron why you're charging them $25 to replace a book they lost when your own catalogue says it only cost $5 [way back in 1979, of course] and I would still rather spend cataloguing time on Authority Records or at least on augmenting the collection with good 520s, genre labels and keywords to improve search results). While I admire the ingenuity of the computer-savvy in creating these wonderful systems -- and Athena is a very neat system that I quite like -- the problems it runs into are largely of its creators own making in deliberating deciding they know better than the sages of LC. When I was in grad school for history, my advisor constantly warned us students of the dangers of present-ism: 'If it's this way now, that's how it will always be, how it always was.' So, while I completely sympathise, Larry, LC-NLC have determined the usage of the field and subfields therein and it really isn't a good idea not to follow form. Who knows what developments in the future will bring? It makes it easier if we're all playing the game with the same rule book, even just for the present, let alone the future. The idea that all cataloguing is isolated from affecting others really belongs to the pre-MARC/online era. If we all follow the rules, we can all help each other out now and in the future. In the alternate mapping I suggested (and keep in mind, that's only my off-the-cuff attempt; it has no particular authority), I assumed you wanted to use the one field 852, so I just chose subfields that would allow you to do what you wanted within that one field. (BTW if the tab thing you were writing about to Derek would allow keeping the data in allowed subfields only, that would be preferable to what I suggested viz. a $d or $w.) When I was first confronted with this, I was mighty perturbed. I understand that Athena's programmers wanted to collect the data in one field: all they needed to do though was use multiple 852 $x fields! There is no reason at all for their creativity!! Following the rules would actually simplify matters. Personally, I would have preferred the data to be placed in a good old 037 tag. To my mind, its subfields provide for all of the above, plus it can be entered at the time one creates a temporary minimal record (to indicate to patrons searching that an item is on-order for example) without the need to muck about with the 852 or other call number field until the work is received in cataloguing. The map for the 037, is simple $a Stock number - possibly useful for re-ordering/replacement $b Source of stock number/acquisition ** $c Terms of availability = (in almost all cases) price ** $f Form of issue - easily adaptable to be an institution's needs with a ltd. institution-specific set of terms or more ones more generally recognised $n Note - where you could easily enter acquisition fund (usually coded in most institutions anyway), order date and received-in date ex. 037 _ _ $bBook Barn $c$22.50 $c$5.00 (sale price) $fTrade pbk. $nGenBkFund; ordered 20021209; received 20030108. Not very standardised, as you rightly hint. Or at least, not so much in the details. Core fields like the 008, 100, 245, 250, 260, 300 tend to be pretty good. But that doesn't mean we should stop trying. If it makes you feel any the better, I keep running across records in the NLC database where contributing cataloguers still aren't even following ISBD description rules for newer records (ca. 1985) and the ISBD rules, IIRC, are older than me! As a cautionary tale, let me warn you about what happened to one school division in Winnipeg. For years that division (and the one I reside and have worked in) used TKM Microcat, a decent system for when it was first created. They were told not to bother coding the 008 -- a core required field -- because that system didn't really use it (can't sort results by date, e.g. because of this). That minor reduction in labour over the years came as little comfort to the division's cheque book a few years back when all the schools had to send ALL their records for RECON because the new system they migrated to was MARC-compliant and viewed the records it was fed as the garbage they were! I kinda think LC should start gathering up a page of horror stories like this to remind folks why it is important to follow those nagging standards, even when it doesn't seem to have any purpose at the time. ;-) In any case, LC sets the structure (and it isn't completely autocratic BTW: someone at your level of authority in a library can make suggestions; my former supervisor did) and if you think it's difficult now, think what might happen if they designate something your system was using for a different purpose and many others go along with the change. Either 'welcome back to the age of splendid isolation' or See above for 'The moral of the story is ...' I would've brought you a thank-you card and cake! ;-) I agree. Plus making the patrons feel more at ease and part of the positive change, and this is of no inconsiderable value! Anyway, I hope some of what I've said this time makes sense, too, and that it may be useful to you and others. Cheers from Winnipeg, Steven F. Baljkas library tech at large Koha neophyte _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha