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