- Koha - lists.katipo.co.nz

Re: [Koha] [BUG] barcode mandatory or not ?
by baljkas＠mb.sympatico.ca 26 Sep '03

26 Sep '03

Friday, September 26, 2003 15:28 CDT Hi, all, Stephen Hedges noted that at NPL they >have in the past used [the] catalog to store pieces of information >that were not physical items, like names and addresses of local social >agencies, and websites (before we had Koha). That would allow people >to search for something like "poverty" and get hits not only on books >about poverty, but websites about poverty and the names of local >agencies that deal with poverty. That is super! I tried to convince a social service agency that this was a feasible thing to do with a library catalogue when I was a volunteer library coordinator years ago. (For the MARC'ists in the Koha community, you may note: while websites can be coded in 'regular' MARC21 (electronic resources, I believe still), so can agencies and individuals. The MARC fields are slightly different from normal (i.e. a book), but the information is online at the LC website under the rubric Community Information at URL <http://www.loc.gov/marc/community/eccihome.html> ) >If the catalog is used to store information that does not relate to a >physical item, then the barcode should not be mandatory. As for non-physical items like websites: that is an excellent point, Stephen. I ran into a problem with the Athena system because it was nigh impossible to convince it that websites didn't need a barcode and we ended up creating fake ones just so it would let us be. Plus the listserv already received the example from a barrister in the UK about libraries that had 24-7 potential patrons but not 24-7 library circ service. The military library where I last worked as a cataloguer had that situation and we actually used manual (logbook) circ instead of the system's circ module. This also allowed us to allow students/staff to sign-out newly received items if needed before cataloguing could be completed. Luckily, our MicroCat system didn't require a barcode. >However, I think the templates for adding and editing items should then >be set to return a warning, in case someone mistakenly enters a >physical item without a barcode. Also an excellent idea! Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, CANADA

1 0

Low-end Koha: after the hardware
by Rich Churcher 26 Sep '03

26 Sep '03

So I've cobbled together a server for my primary school library project. It's an AMD Athlon 700 MHz chip on an Asus motherboard, 20 GB Seagate HDD, a 10/100 card, 128 MB SD-RAM (which I'll double before hooking it up to the network) all wrapped up in a cheap Koala ATX case. Some donated, some bought new. I'm almost done with installing Linux (doing the Kernel compile as I write this. So the next stage is upon me: getting the library data out of Catalist and into Koha. My first question is, what's the best way to export the Catalist database? Bear in mind I'm not a librarian (I grok a fair bit of database-speak though). I'm assuming this involves MARC in some way, but I'm going to need some details on how to proceed. -- Cheers, Rich.

4 6

Koha link image
by Rich Churcher 26 Sep '03

26 Sep '03

Is there a button I can use to link to Katipo's site, or for that matter as a link from a general intranet site to a local Koha installation? I was going to use one of those little purple taniwha guys on koha.org, but of course would not want to do so without permission. -- Cheers, Rich.

3 2

Re: [Koha] [BUG] barcode mandatory or not ?
by Stephen Hedges 26 Sep '03

26 Sep '03

Paul asks: > The question is : what is the good behaviour ? > * barcode IS mandatory => manage this in checker, > the tools that checks > that your DB is correctly parametered. > * barcode IS NOT mandatory => change non-MARC > part of Koha to accept > empty barcodes. At NPL, we have in the past used our catalog to store pieces of information that were not physical items, like names and addresses of local social agencies, and websites (before we had Koha). That would allow people to search for something like "poverty" and get hits not only on books about poverty, but websites about poverty and the names of local agencies that deal with poverty. If the catalog is used to store information that does not relate to a physical item, then the barcode should not be mandatory. However, I think the templates for adding and editing items should then be set to return a warning, in case someone mistakenly enters a physical item without a barcode. Stephen Hedges Nelsonville Public Library

1 0

Re: [Koha] Passwords
by Stephen Hedges 26 Sep '03

26 Sep '03

Mark, this is already a bug, no. 532. Now if someone would like to fix it ... ;-) Stephen Hedges Nelsonville Public Library > On 2003-09-24 10:58:37 +0100 T & J Kotula > <tjkotula(a)paradise.net.nz> > wrote: > > > "You have entered a UserID that already exists. > Please choose another > > one". > > Are you entering a UserID, even their member > number? If I can > reproduce this, I'll bug report it or tell you > how to avoid it. > > -- > MJR/slef My Opinion Only and possibly not of > any group I know. > http://mjr.towers.org.uk/ > gopher://g.towers.org.uk/ slef(a)jabber.at > Creative copyleft computing services via > http://www.ttllp.co.uk/ > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

3 3

Passwords
by T & J Kotula 26 Sep '03

26 Sep '03

Hi, Can anyone tell me how to set up a password for a user? I tried going through "Change Password" from the members page, but everytime I try to change the password, once I click "Confirm Password", Koha2pre4 tells me "You have entered a UserID that already exists. Please choose another one". Thanks tomasz kotula

2 1

Re: [Koha] inconsistencies in acquisition.simple process
by baljkas＠mb.sympatico.ca 26 Sep '03

26 Sep '03

Thursday, September 25, 2003 21:39-23:12 CDT Chris Cormack <chris(a)katipo.co.nz> wrote: >> >[snip] >> >But I think the form has been designed in a way so that it looks >> >like we'd need 3 biblios for the above example .. which is not >> >right. >> >> That's where you have things wrong, my friend. [snip] >> *** Three different items do require three different records. *** >> >Ahh, see this is where I think people confuse internal storage with >external representations. Okay, I think I see where we are getting confused. The external representations as you termed them are what the basic bibliographic library record MUST describe. This is the data that is coded in a MARC system, just as it was 'coded' in the areas of old catalogue cards. The system of authorities (proper or authorised or used forms, cross-references, see also's, broader terms, narrower terms, related terms) belong to another level. Although some bibliographic records have embedded authorities (this was noted in passing recently in follow-up to the questions about Koha usage of 090 for call number), most systems try to separate the two distinct functions/levels. What is happening, in essence, Chris, is prioritizing of the authority (what the biblio is acting as) at the expense of the bibliographic record (what Koha terms the biblioitem). There is no simple, neat way of having one 'master' record for different physical manifestations of the work (again, not talking about FRBR). I think in terms of MARC record coding, so perhaps this is more evident from that viewpoint. Let me try an expansion of your The Lord of the Rings example from a MARC perspective. For each of the different physical manifestations of that work in the collection, the regular print book, the DVD, and the large print work, you need a separate record. There are differences, automatically, in the following MARC coding fields: · 001 - representing the digital accession number, if you will · 005 - when exactly the object entered into the library system (impossible to be the same for different items!) · 006 - fixed-length data field required for the DVD, because it does come with accompanying text materials (not needed for the books) · 007 - fixed-length data field required for the DVD, but not for the books · 008 - fixed-length data field required for all 3, but the coding in each is different, e.g. with 9=any number, #=blank and L=any letter 'regular' book 008 999999s9999####LLL####g######000#1#eng#d Large Print book 008 999999s9999####LLL####gd#####000#1#eng#d DVD 008 999999s2009####LLL999#g|||||#####vceng#d Admittedly, these are close, but they are not identical · 010 - different for the books and possibly nonexistant for DVD · 020 - (ISBN) same as with 010 · call number - almost certainly different for all 3 since few libraries shelve multiple formats together. · 100 - MAIN ENTRY The fun really begins with this core field, though. The DVD, as much as we all love Tolkien, would not have him as the author in 100 because, by definition, the film is a work with shared responsibilities. LC has a relevant exemplum in the record for the first movie, which removes Tolkien from the 100 (although I'd question the absence of a 700 for him and for the director). · 245 - The title and statement of responsibility would have a different [GMD] h subfield for each form of the item, i.e. 'regular' book 245 14 $aThe lord of the rings :$h[text] |--- usually omitted Large Print book 245 14 $aThe lord of the rings :$h[text (large print)] DVD 245 04 $aThe lord of the rings :$h[DVD videorecording] . 250 - would record different editions for the text · 260 - would have different publishing information for all · 300 - would show different physical details for each item, e.g. 'regular' book 300 ## $a299 p. ; 18 cm. Large Print book 300 ## $a699 p. ; 28 cm. DVD 300 ## $a1 videodisc (ca. 3 hours) :$bsd., col. ; $c12 in. +$e1 booklet. There is a reason that the library card catalogue and MARC after it are item-based. In a traditional system, card or online, the title alone would act to gather these three different entities together. (Each of their records (in some way) would indicate the number of copies held.) So, I guess, I would have to ask, how in the world does the biblio level store ALL that data, with all the differences, and then parse it into the 3 distinct entries for the 3 different types of items? That seems to me more complex than the repetition that might exist. In fact, for your example, the only part that I can see as repeating, would be title parts of the 245 (depending on who coded them, a and b and/or p subfields) and maybe a 520 summary. Otherwise, the rest of the data would be different. (It is not correct, BTW, to code properly for one entity (say, the first in the collection) and then base other items off of that when they differ.) I don't understand the rationale for the biblio level unless it is acting as an attempt at an authority. From a MARC-perspective, the utility of the biblio level is confusing. I would still rather see a fully developed authority system (although I realise that it is ridiculously simple to express one's druthers especially when one has no idea how to program a system to do it or how complex such a task is). Chris, I hope that this is not just frustrating to you. But I really don't see what the biblio level is trying to do or how it simplifies storage at all. >If I can export records in a format like that, [etc. snip] Like what? Really, I don't know what you mean. >What I was talking about is how Koha stores the data .. I think if its >possible to create valid catalog records that correspond with >standards, then how we store the data internally doesnt matter. Certainly, but I don't understand how it's being stored in this way nor how parsing out the proper information is in any way 'easier' than having it based on the biblioitem level, say. >Apart from the obvious storing it in a way that provides for fast >access. And minimal redundancy. Redundancy is avoided by checking for items already in the collection. Strictly speaking, a new record is required by each different manifestation of the work (although this is sometimes ignored in practice). For example, in the military library where I last worked as a cataloguer, we had 5 different editions of a work by Cajus Bekker on the Luftwaffe: following the rules strictly, we had 5 different records, with 2 copies each of the 2nd and 5th noted in the holdings (ironically also in a 090 field subfields c and p, in the system we were using). >Perhaps I didnt make that clear enough in my message :) I was talking >about the internal structure. Maybe you could point me and others in the right direction to see how the internal structure is working to do this. I really don't get it. Thanks again, Chris, Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, CANADA

2 1

Re: [Koha] inconsistencies in acquisition.simple process
by baljkas＠mb.sympatico.ca 26 Sep '03

26 Sep '03

Thursday, September 25, 2003 18:25 CDT Hi, Chris, Regarding your comment in answer to Pierre's inquiry >biblio has things like title, author, copyright date etc. >biblioitems has number of pages, itemtype, call number etc items has >accession date, location (which branch etc) > >So the potential is you should have 1 biblio, 1 or many biblioitems, >and 1 or many items. > >Lets take The Fellowship of the ring. >We might have 2 copies of the DVD 3 of the book, and 1 large print >version say. >So we would have 1 biblio. >3 biblioitems (1 for dvd, 1 for fiction, 1 for large print) >and 6 items (2 attached to the dvd biblioitem, 3 attached to the >fiction and 1 to the large print) > >So that's how the internal storage works. > >Of course we can make it appear to the librarian or the borrower as if >we have 1 biblio, and 6 items ie abstract over the biblioitems. >But I think the form has been designed in a way so that it looks like >we'd need 3 biblios for the above example .. which is not right. That's where you have things wrong my friend. Beyond the MARC stuff, which I know is not your responsibility or interest, whatever library advice you are getting is WRONG. *** Three different items do require three different records. *** You have three different physical manifestations of a work, which, if we are still using AACR2R rules -- which are the standard for the anglophone library world ascribed to and endorsed by your National Library as well as those of the Australia, Canada, the United Kingdom and the United State -- the RULES require three different records. The biblio level that you all wisely created acts like an authority record, pulling together different manifestations of a work, because, God only knows what the patron might actually want. But you have to remember that that's all it should do then. As a pure matter of what is correct, 3 different types of item (book, DVD, large print book) require 3 different records, which would have slightly different data and different MARC coding. If you want to keep the biblio level, then work should begin on making that into the core of the AUTHORITIES for the system (used forms, cross-references, see also's etc.). As a small aside, different ***editions*** of the same work should also have separate records. Only multiple copies of the same item should be bound in together by some kind of holdings data. And to forestall the FRBR people, please realise that most people are not rushing headlong to embracing that different perspective: most of us are quite content with AACR2R and will be for some time to come. Thanks for letting me vent again, Chris. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, CANADA

3 2

inconsistencies in acquisition.simple process
by Pierre Cauchois 25 Sep '03

25 Sep '03

Hi all, I'm working on fitting the acquisition.simple process to the needs of the ESIEE library, and something is bugging me on the addbiblio.pl page. Why do pieces of information like place, number of pages or itemtype should appear here, on the bibliographic notice form, and not on the item form (the next page)? Because of that, we are obliged to create two different notices for the same bibliography if we want two items to be in different places. Worse, the fields concerning place and itemtype duplicate themselves strangely when a bibliography has several items. Can someone explain me the technical reasons of this "inconsistency", if it's one? thx /pierre

2 1

Support
by sridhar 25 Sep '03

25 Sep '03

Dear Sir We are a Open Source Software development company, based in Chennai, Tamil Nadu, India having lots of experience with open source software, and are interested in promoting and offering commercial support for Koha Library Systems. Thanks and Regards N. Sridhar email: sridhar(a)mindassociates.com URL: www.mindassociates.com

1 0