[Koha-devel] Re: MARC links

[Stephen Hedges]

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