[Koha] data import question - a few more thoughts

[Bigwood, David]

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 at lpi.usra.edu
Lunar & Planetary Institute



-----Original Message-----
From: baljkas at mb.sympatico.ca [mailto:baljkas at mb.sympatico.ca]
Sent: Thursday, July 24, 2003 7:51 PM
To: larry at larrystamm.com; koha
Cc: baljkas at 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 at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha