- Koha-devel - lists.koha-community.org

[Bug 217] New: querying with barcode to modify biblio
by bugzilla-daemon＠wilbur.katipo.co.nz 21 Mar '03

21 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=217 Summary: querying with barcode to modify biblio Product: Koha Version: CVS Platform: PC Status: NEW Severity: enhancement Priority: P2 Component: Acquisitions (Simple) AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: paul.poulain(a)free.fr QAContact: koha-devel(a)lists.sourceforge.net to modify a MARC biblio, you can search with ISBN or title. Would be nice to add search with barcode number ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Re: MARC links
by Stephen Hedges 21 Mar '03

21 Mar '03

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

3 2

Koha Bug Report (fwd)
by Pat Eyler 20 Mar '03

20 Mar '03

Congrats on all the hard work! The queue is draining. -pate Bug Report for -All- Thu Mar 20 20:13:03 2003 Summary New Bugs This Week 1 Bugs Marked New 39 Bugs Marked Assigned 5 Bugs Marked Reopened 0 Total Bugs 44 Bug Count by Engineer Owner New Assigned Reopened Total a.c.li(a)ieee.org 1 0 0 1 chris(a)katipo.co.nz 22 2 0 24 paul.poulain(a)free.fr 1 0 0 1 tonnesen(a)cmsd.bc.ca 15 3 0 18

1 0

acquisition and cataloguing (again...)
by paul POULAIN 20 Mar '03

20 Mar '03

Hi all, The 1.9.1 is almost ready to be released. In this version cataloguing and acquisition are fully working (at least, I'll ask you to test if it is :-) ) Please take a deep look at this mail, and answer the ending question if you have an opinion/idea. How it will work : * as we spoke before, they are 2 differents processes. ACQUISITION =========== * search/select the supplier * select *order* option * search for a book, * select it if it's in the DB and you just want to buy a new item. * you add a new (small) biblio if you must create a new biblio * when item recieved, you complete some informations (barcode...) that's all. CATALOGUING ============= * search book in catalogue option, or, at your option in MARC option (new menu in top of screen) * depending on MARC system parameter (ON or OFF), the biblio is shown in standard form, or in MARC. * select "edit" link. * modify the biblio and/or items (in MARC or standard form, depending on the form you were looking at). * You can at any time split between normal and MARC form of the biblio. * At your option, you can enter biblio directly from MARC menu, without acquisition process. FUTURE ======= With such a way to do, we should be able to add in the MARC menu a "commercial cataloguing import" to import complete notices from a "commercial" CDROM and automatically replace the manually entered notice. It will be done after 2.0 i think. RFC ==== My question is around z39.50. I plan to add a link in some biblio acquisition that will "magically" find biblio from z39.50 servers. The idea is : * i'm entering a biblio, that is not in breeding farm or is poorly entered in koha. * I clic on "magic z39.50" link * a page appears and shows notices founded from z39.50 servers (with same ISBN/ISSN or title/author) * the user selects whatever he wants. * koha goes back to biblio entering, with magically entered values. Such a feature could be possible : * during direct MARC cataloguing (the one without acquisition process) * during biblio modification What do you think of this idea ? it will be implemented after 1.9.1, as it's a non-trivial job (for 2.0RC1 probably). -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: MARC links
by paul POULAIN 20 Mar '03

20 Mar '03

Stephen Hedges wrote: >Paul (amd Chris) - > >I've attached my list of suggested links between the koha database and the MARC >database. > >As you can see, some of the links need to be repeatable. 1.9.0 currently >accepts only the last link that's entered when there are duplicate links, which >means the "Checks MARC" function always reports errors. > >I've sprinkled other comments in the body of the text attachment. > >Stephen > 1 month after, I haven't forgotten this mail, and use it. I try to improve the MARC21 english parameters for 1.9.1, to have a working parameters in the release. [biblio table] biblionumber 090 c Koha biblionumber author 100 a Personal name title 245 a Title unititle 246 a Title proper/short title notes 500 a General note serial 400 v Volume number/sequential designation seriestitle 440 a Title copyrightdate 260 c Date of publication, distribution, etc 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./ abstract 520 a Summary, etc [biblioitems table] biblioitemnumber 090 d Koha biblioitemnumber biblionumber 090 c Koha biblionumber volume 440 v Volume number/sequential designation number 440 n Number of part/section of a work classification 082 a Classification number [or it could be an extra subfield in the 090 tag, since this + dewey + subclass = callnumber] [classification, dewey, and subclass could also be: classification 852 h Classification part dewey 852 k Call number prefix subclass 852 m Call number suffix] / ==> i've chosen 852 h/k/m, which seems better, and will work fine./ itemtype [this probably should be added as a 955 subfield] / ==> i think you speak of 995, not 955. In this case, it's a bad idea. 995 fiels are related to ITEMS, and itemtype is a biblioitem field. I've choosen 686a / isbn 020 a International Standard Book Number issn 022 a International Standard Serial Number publicationyear 260 c Date of publication, distribution, etc volumedate 260 c Date of publication, distribution, etc /==> multi-linked field... 260c is the only remaining multi-linked field (see below for 500a, and dewey 090b is solved by using 852h/k/m) In fact, those fields are differents things, and i'm surprised to see marc21 doesn't differenciate them. I think our best solution is to choose one, and do with it. /publishercode 260 b Name of publisher, distributor, etc volumeddesc 300 all PHYSICAL DESCRIPTION / ==> I really don't find any MARC21 field for volume desc. Maybe we can ignore this / timestamp 005 DATE AND TIME OF LATEST TRANSACTION illus 300 b Other physical details pages 300 a Extent 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 ?)/ size 300 c Dimensions place 260 a Place of publication, distribution, etc lccn 010 a LC control number marc [what's in this field?] /==> this field is not used, don't worry :-)/ url 856 u Uniform Resource Identifier [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 hare 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 -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

[Bug 54] Pick borrowers by name when setting reserves
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Mar '03

19 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=54 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED OS/Version| |All Resolution| |FIXED ------- Additional Comments From paul.poulain(a)free.fr 2003-03-20 09:36 ------- done in cvs. works only if exact firstname and chooses the 1st name only ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 48] marcimport.pl should do a better job at guessing the itemtype
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Mar '03

19 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=48 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From paul.poulain(a)free.fr 2003-03-20 09:20 ------- out dated ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 118] searching
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Mar '03

19 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=118 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From paul.poulain(a)free.fr 2003-03-20 09:15 ------- already fixed ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 60] invoice
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Mar '03

19 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=60 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From paul.poulain(a)free.fr 2003-03-20 09:13 ------- out of date bug ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 103] Need additional Perl module checks in installer.pl
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Mar '03

19 Mar '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=103 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From paul.poulain(a)free.fr 2003-03-20 09:12 ------- already fixed ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0