[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Koha-devel] Re: MARC links
From: |
Stephen Hedges |
Subject: |
[Koha-devel] Re: MARC links |
Date: |
Thu Mar 20 13:32:05 2003 |
Hi, Paul. Looks like you've been busy! I have a couple of comments on your
notes:
> timestamp 005 DATE AND TIME OF LATEST
> TRANSACTION
> [computer generated]
> /
> ==> for instance, timestamp is not auto-managed
> in koha. It should be
> possible to develop a plugin to do this./
Now that I'm beginning to become a semi-geek :-) , it seems to me that the
timestamp columns in Koha would be automatically updated by MySQL whenever the
record is inserted or updated, so long as that column is not specifically
addressed. I'm basing this on http://www.mysql.com/doc/en/DATETIME.html .
Maybe somebody on the developers list can confirm that?
> itemtype
> [this probably should be added as a 955
> subfield]
> /
> ==> i think you speak of 995, not 955.
Yes -- mea culpa.
> In this case, it's a bad idea.
> 995 fiels are related to ITEMS, and itemtype is a
> biblioitem field. I've choosen 686a/
I don't see any 686 tag in MARC21. But as you say, this is not a piece of
information that would normally be associated with an individual MARC record,
so it may not matter where we put it.
> volumeddesc 300 all PHYSICAL DESCRIPTION
> /
> ==> I really don't find any MARC21 field for
> volume desc. Maybe we can ignore this
> /
Sounds like a good idea to me.
> notes 500 a General note
> /
> ==> As 500a is already used for biblio notes, i
> don't know where to put
> biblioitem notes.
> Note too that i think biblioitem notes is a
> unuseful field (biblio.notes
> and item.notes are enough no ?)/
Again, I totally agree.
> [items table]
> [lots of gaps here, all needing new 995
> subfields?]
>
> /==> I've added some, and there's no problem to
> have unmapped fields.
> For example, i don't think it's important to have
> prices and bookseller
> info in the MARC record.
> /
> itemnumber 995 s Koha item number
> biblionumber 090 c Koha biblionumber
> multivolumepart
> biblioitemnumber 090 d Koha biblioitemnumber
> barcode 995 f barcode
> dateaccessioned 995 m dateaccessioned
> booksellerid
> homebranch 995 d homebranch
> price
> replacementprice
> replacementpricedate
> datelastborrowed
> datelastseen
> multivolume
> stack
> notforloan 995 o notforloan
> itemlost
> wthdrawn
> bulk
> issues
> renewals
> reserves
> restricted
> binding
> itemnotes 995 u item notes
> holdingbranch
> paidfor
> timestamp 005 DATE AND TIME OF LATEST
> TRANSACTION
Well, there are a few things here that would be very handy for a library.
Price and replacement price are two, for example, that a library would use to
determine how much to charge a borrower for a lost item. I think they sould be
part of the MARC record. datelastseen comes in very handy when doing
inventory, since you can print a list of items that have not been "seen" for
six months and then go searching for them -- but it's odd to have that as part
of a MARC record. How would you update it? issues, renewals, and reserves are
handy for statistics, but that seems like it would be handled better somewhere
other than the MARC record. And holdingbranch is nice to be able to tell where
an item is, when branches send items back and forth -- but again, it would be
more efficient to handle this outside of the MARC record.
Generally, the MARC record is done once and only once, and is not continually
updated with transaction data. Don't you agree?
So I think price and replacement price should be added to your mapping of the
995 tag, but the rest of this handy information should be stored elsewhere.
Stephen Hedges
Nelsonville Public Library