- Koha - lists.katipo.co.nz

New to KOHA
by Marie Wardall 26 Feb '06

26 Feb '06

Our school district is building a new K-5 building to open in the fall and we are looking into opening the library using KOHA. I will be the librarian in the new building and have been looking into and trying things out in the KOHA demo. Our new school would be the pilot school for KOHA in the district and if things went well then it would be inplemented throughout the district. Currently our district uses Library software from Follett. The other librarians in the district have a lot of concerns about KOHA and are hesitant on change. I want to be able to show them that the things they are used to now and some of the improvements they would like to see can be achieved with KOHA. So here are some things that come to mind after looking at the demo and speaking with my collegues: *Currently, when checking out a student, the picture of the student appears on the screen so that we can verify who the student is. This is more important at the secondary level, but also relied on in the elementary level when you are getting to know who the child is. Is this possible in KOHA? *WE use a Student Management System called Starbase to dump student records into Follett each Fall. This is crucial in getting ready for classes each fall because it is a very big time saver. The little I know about how different systems work I would think that we would be able to do the same with KOHA...am I correct? *Barcodes-Our current barcodes are 5 digits long with a leading T for a material barcode and a leading P for a patron barcode. Looking at the demo it appeared that the barcodes are 8 digits long. Can this be changed when going through the setup of the system preferences? If we would go with KOHA and the rest of the district would get switched over we would need to be able to keep the same barcode numbers on books because re-barcoding the collections would be an enormous job. *One last thing for now, as I am sure I will have others as I investigate more and am able to work through the setting up of the system preferences, is that in the Cataloging on the demo there is a Default Marc record framework and a Test Marc record framework I could choose from. I'm thinking I could set up different frameworks here for the different types of materials that I catolog such as book, video, DVD, CD, equipment and an easy MArc for when I don't need or want a complete marc record. Once I set up those different MArc frameworks when I would catalog I could just choose the framework and put in the information that was needed for that type of material or item...right? Thank-you for any insight or comments you can give regarding these questions/comments. My questions are lees technical than the others I've seen here, but are important in educating myself and they others in my district about what KOHA can do for us. Marie J. Wardall Teacher-Librarian Rothschild Elementary School Rothschild, WI 54474 715-359-3186 ext.5424 mwardall(a)dce.k12.wi.us

2 1

Re: Re: [Koha-win32] Re: [Koha] Tag 880
by Steven F.Baljkas 25 Feb '06

25 Feb '06

Friday, February 24, 2006 19:21 CST Hi, Carol, Joshua, et al., Just catching up with the e-mail a little late today. Carol had posed a question a while back on getting actual Chinese characters both in MARC records and out in the Koha OPAC display. I had suggested MARCEdit might be able to help with some things in the past, but if memory serves -- I'm not 100% on this and you would have to check the MARC standards online or in print to confirm this but--, the $6 linking fields have to be generated by the ILS itself to provide such linkages. Most of the ILS I have experienced simply cannot do this. (I assume that Voyager and Aleph can because they are known for multiscript abilities.) I don't think Koha can (not that that is a bad thing for this stage in its development, considering the complexity and rarity of the need for $6 linkages). The purpose of the 880, Joshua, according to my erstwhile go-to guy on the history and evolution of MARC coding, was to hold non-Roman script characters. I gather that, although computers may have been able to code for them for a long while now (since the 1960s? via hexadecimal and ASCII and Lord knows probably other codes), there weren't any ILS at the beginning that could make use of them. Hence, 880 and associated fields were contrived so that data could be preserved against loss (recall our discussion of backing things up: I tell you, we cataloguers are THE pre-eminent packrats of humanity - no iota to be lost! ;-D). If I recall my original advice to you, Carol, it was to ***try to see if Koha could display the original Chinese script correctly in the 100 and 245 fields*** (and for that matter, the other core descriptive fields, although I know I didn't say that before). I know that there have been questions -- some of them intiated by you, IIRC -- on UTF8 etc. that are relevant to this. I just don't know what Koha's status is on using non-Roman scripts. Sorry. It would be really good to know how that works though. From what I am used to seeing in other ILS, it usually requires that the cataloguers enter special codes -- either hexadecimal or system proprietary ones -- in order to ensure that special characters will display properly for patrons (usually, the cataloguers end up having to look at codes or messy weird stuff in place of real letters or logograms). Continuing the re-iteration of my original advice to you, Carol: if you are able to put the actual Chinese characters into the 100 and 245, you could use a 700$a or 900$a to provide access to the author entry transcribed, and perhaps a 242 (technically TRANSLATION of title, which is never a bad thing), 246, 700$t, 730 and/or 740 fields to provide transcribed title access. Although anyone who knows me knows I actually like the cataloguing rules, what I am proposing (other than the 900$a which is free to do with as you please) bends if not breaks the cataloguing rules. However, it should work, given that Joshua has assured us that Koha can access 700 fields (at least from 2.2.5 on) and 246s. A quick word about transcriptions, because I know this topic has caused headaches for Chinese-language cataloguers. In 2000, LC prescribed that the Pinyin system of romanization was to supersede the previously used Wade-Giles system. Carol, ***if you are retrieving older MARC21 (really USMARC, etc.) records, you may very well have to move the transcribed fields and create the now REQUIRED pinyin transcriptions.*** (There is not, so far as I know, a requirement to DELETE the older Wade-Giles transcriptions, but someone working directly in the field may well correct me on that point .) Now, Carol, please also note: you can take all this with a grain of salt (ignore it) if you don't care about having your library comply with the ALA-LC practices mandated in this case. I have seen libraries request and rely on their own transliteration systems for Russian and Ukrainian so I know that ALA-LC practices are not always heeded when it comes to dealing with non-Roman script cataloguing matters. I hope that this re-iteration and amplification will help somewhat. I am very interested to learn how this resolves for you and I do hope it will work out well. Best wishes with this tricky problem! Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada ============================================================ From: Carol Ku <carolcool01(a)yahoo.com> Date: 2006/02/24 Fri PM 03:41:35 CST To: Joshua Ferraro <jmf(a)liblime.com> CC: Koha Mailing List <koha(a)lists.katipo.co.nz>, Koha Windows <koha-win32(a)nongnu.org> Subject: Re: [Koha-win32] Re: [Koha] Tag 880 You are perfectly right. I noticed that most libraries such as Library of Congress, they represent Chinese pinyin in tag 100, and this piece of info is linked to tag 880 $6100 and with other related subfields etc... We would like to do the following: 1) save the pinyin and Chinese in Koha. 2) Display Chinese info in OPAC 3) Allow user to search using pinyin if they don't have Chinese input Since Koha display only one line item for title, author etc, we are thinking may be we need to use MARCEdit to tweak tag 100 to 880 $6100. I was advised by others that I should instead designate new tag e.g. 900 for tag 880 $6100, 901 for tag 880 $6245 etc. To make things more complicated, MARCEdit does not seem to recognize the $6 link either. So it will treat all tag 880 as one tag. Joshua Ferraro <jmf(a)liblime.com> wrote: On Fri, Feb 24, 2006 at 12:26:29PM -0800, Carol Ku wrote: > i think the $6 linking field is different from a regular > subfield a, b or c > etc. > > In MARC, all the information on the book will be stored in the native > language in tag 880. Then they use $6 linking field to tie 880 to tag 100 > for Name etc... so e.g. 880 $6100 a.... so this tag means information > stored here is the author name (designated by code $6100) in e.g Chinese. > $6 is not a regular subfield.... OK ... first let's discuss what you're trying to do. I have had two years of Chinese language classes so I know that there are several ways to represent Chinese. Are you attempting to put 'pinyin' in the 100a and then link to the actual characters in 880? What is your goal in using the 880? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

3 4

Re: Re: [Koha-win32] Re: [Koha] Tag 880
by BWS Johnson 25 Feb '06

25 Feb '06

Salvete! >Eat your heart out Voyager :-). :) This is hot! Support for Koha is totally better than commercial products. >From what I gather, this seems like it will be around post MARC, too. Brooke @ Hinsdale MA

1 0

some perl lines
by Wojciech Zatorski 25 Feb '06

25 Feb '06

Hello koha, why are this lines in koha code? if ($fields[$x_i]->tag() eq $fields[$x_i-1]->tag()) { $tag_data{tag}=""; } else { $tag_data{tag}=$fields[$x_i]->tag().' -'. $tagslib->{$fields[$x_i]->tag()}->{lib}; } because this lines of marc display are incorrect with marc standards (for example field 650)... bye -- <wojciech(a)zatorski.net> tel. +48 509-855-239; GG: 1500861; Skype: zatorski http://www.Zatorski.Net -- Actions speak louder than words.

1 0

Re: [Koha] The '650x' problem
by Joshua Ferraro 25 Feb '06

25 Feb '06

On Fri, Feb 24, 2006 at 02:37:37PM -0800, BWS Johnson wrote: > When I tried to do this, I got this page. Yea ... sorry about that ... I was missing some cgi params. Try this: http://koha.liblime.com/cgi-bin/koha/search.marc/search.pl?type=intranet (it's just the regular advanced search page on any Koha intranet) Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

RE: [Koha-win32] Re: [Koha] Tag 880
by Bigwood, David 24 Feb '06

24 Feb '06

I can't comment on your problem, but maybe this will help somewhere in your project. MARC::Detrans - De-transliterate text and MARC records <http://www.furl.net/item.jsp?id=4638566> MARC::Detrans is an eclectic addition to the already eclectic MARC::Record distribution for de-transliterating MARC::Records. What is detransliteration you ask? Well it's the opposite of transliteration, which according to the Merriam-Webster: to represent or spell in the characters of another alphabet. Traditionally when librarians catalog an item that has a title in a non-Roman script they will follow transliteration rules for converting the title into the Roman alphabet, so that the bibliographic record could be filed into the card catalog or database index appropriately. These Romanization Rules are published by the Library of Congress http://www.loc.gov/catdir/cpso/roman.html. http://search.cpan.org/~esummers/MARC-Detrans-1.2/lib/MARC/Detrans.pm Sincerely, David Bigwood bigwood(a)lpi.usra.edu <mailto:bigwood@#lpi.usra.edu> Lunar and Planetary Institute http://www.lpi.usra.edu/library/whats_new.shtml Catalogablog http://catalogablog.blogspot.com <http://catalogablog.blogspot.com/> _____ From: koha-bounces(a)lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Carol Ku Sent: Friday, February 24, 2006 3:42 PM To: Joshua Ferraro Cc: Koha Mailing List; Koha Windows Subject: Re: [Koha-win32] Re: [Koha] Tag 880 You are perfectly right. I noticed that most libraries such as Library of Congress, they represent Chinese pinyin in tag 100, and this piece of info is linked to tag 880 $6100 and with other related subfields etc... We would like to do the following: 1) save the pinyin and Chinese in Koha. 2) Display Chinese info in OPAC 3) Allow user to search using pinyin if they don't have Chinese input Since Koha display only one line item for title, author etc, we are thinking may be we need to use MARCEdit to tweak tag 100 to 880 $6100. I was advised by others that I should instead designate new tag e.g. 900 for tag 880 $6100, 901 for tag 880 $6245 etc. To make things more complicated, MARCEdit does not seem to recognize the $6 link either. So it will treat all tag 880 as one tag. Joshua Ferraro <jmf(a)liblime.com> wrote: On Fri, Feb 24, 2006 at 12:26:29PM -0800, Carol Ku wrote: > i think the $6 linking field is different from a regular > subfield a, b or c > etc. > > In MARC, all the information on the book will be stored in the native > language in tag 880. Then they use $6 linking field to tie 880 to tag 100 > for Name etc... so e.g. 880 $6100 a.... so this tag means information > stored here is the author name (designated by code $6100) in e.g Chinese. > $6 is not a regular subfield.... OK ... first let's discuss what you're trying to do. I have had two years of Chinese language classes so I know that there are several ways to represent Chinese. Are you attempting to put 'pinyin' in the 100a and then link to the actual characters in 880? What is your goal in using the 880? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [Koha] Tag 880
by Steven F.Baljkas 24 Feb '06

24 Feb '06

Tuesday, February 14, 2006 23:08 CST Hi, Carol, Just in quick response to your inquiry, which I noted before and was hoping somebody more knowledgeable on MARC coding history would respond to ... Now, Dave Bigwood or other cognoscenti can correct this if I have it wrong, but I was given to understand some years ago by an authority I trust that fields like 880 are basically the vestigal remains of the inadequacy of earlier computer systems. When they were conceived, computers were just beginning to be able to handle more than Latin letters with the occasional accent (whereas now we are almost at the point where alternate scripts could be encoded within the same field, as was originally desired/intended -- see AACR). I don't know what Koha's coding of the various scripts used by various languages allows for, but I understood it could handle both roman and non-roman scripts at the same time. ***If that is correct, I don't see why you would need to use the 880 at all. Moreover, even if you still want to do so, Carol, Koha doesn't -- that is, at present, it CAN'T -- make use of the required $6 linking subfield.*** I can't see how you would overcome that barrier without a heavy investment in programming. While you cannot repeat the 100 and 245 in a valid MARC21 record, you can work your way around these limitations (rules) easily enough. For example, one could opt to display a 900 field that could give an alternate graphic representation of the 100. Many ILS make use of 900 to allow for alternate forms of the 100 (an embedded authority). I should think you could add a 900 to your Koha MARC records and display. For the 245, assuming that one is using the 245 for the title coded in the actual non-roman script of the language, one could make use of the 242, Translation of the Title by Cataloguing Agency, to record the romanized transcription and translation. Alternatively, one could make use of a 246. If neither of these solutions is satisfactory/to your liking, as my cataloguing instructor would say, there are always Notes. Whatever you decide to do, just be sure to save your original records first in case you need to revert back to them at a later stage. Hope this helps a bit. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada P.S. If you still get no response from people with actual experience with the 880, I would suggest writing to one of the language areas at LC that would have recourse to it to see what they would suggest. ============================================================ From: Carol Ku <carolcool01(a)yahoo.com> Date: 2006/02/14 Tue PM 02:12:07 CST To: Koha Mailing List <koha(a)lists.katipo.co.nz>, Koha Windows <koha-win32(a)nongnu.org> Subject: [Koha] Tag 880 Have anyone successfully imported MARC record with tag 880? In Library of Congress, this field contains information of book stored in its native language. In MARC records, there seem to be some fields to match the information in tag 880 to 245(title), 100 (author name) etc... But I know Koha only has the subfield structure. If anyone has used the tag 880, I would like to seek your advice in this area. Thank you. _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

3 4

Re: [Koha] The '650x' problem
by Joshua Ferraro 24 Feb '06

24 Feb '06

Hi Brooke, Thanks for the explaination! Can you try the MARC search at the bottom of this page: http://koha.liblime.com/cgi-bin/koha/search.marc/search.pl and tell me if it allows you to filter out entries you don't want to view. (does you wanting a Corona mean you don't like the demo? :( or that you do :) ). I'm also going to get authorities records going on that demo which may help further. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

The '650x' problem
by Joshua Ferraro 24 Feb '06

24 Feb '06

Hi all, Could someone explain to me what the '650x' problem is? Is it a matter of not being able to search for subjects in 650x? or is it a matter of not being able to display the subject tags/subfields correctly in the MARC view of Koha? If you could, it would be great to get specific examples so we can efficiently find a solution (if in fact there is a problem). Feel free to use the LibLime demo when refering to such examples: http://opac.liblime.com http://koha.liblime.com Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

Re: Re: [Koha] marc import
by Joshua Ferraro 24 Feb '06

24 Feb '06

On Thu, Feb 23, 2006 at 04:18:02PM -0600, Steven F. Baljkas wrote: > Given the existence of the MARC21 standards, one such expectation is > that an ILS will be able to handle the data encoded in a record WITHOUT > the necessity of teaching the ILS about every field and subfield. In my > library science training, that was considered to be the responsibility of > programmers and developpers: not library staff. (I daresay if programmers > had to start correcting flaws in programming languages touted as ready for > use, it wouldn't be seen as accommodating to tell them that there are > easy solutions at hand.) You have to understand, Steven, that most of the programmers working on Koha have been paid by libraries to develop the functionality that it currently has. They were paid to set things up the way that _those_ libraries needed things set up. Nelsonville is still running version 2.2.0 by the way, and their frameworks haven't been set up properly to handle the 650s. They will be upgrading shortly, and when they do, I think you'll be hard pressed to find a problem. > All the confessions aside, thus, I see no point in pretending we are > having an open conversation towards improving Koha's handling of MARC > when the retorts on the programming side are consistently of the kind > that 'it works well enough' and 'nobody but we MLS will care'. I daresay > that if you were to continue with that line of thinking you would see, > without any contribution on my part, how quickly it leads to disaster. That's not what I'm saying at all. My point is simple: Koha's MARC Frameworks can fully support the MARC Bibliographic Standard if you set them up properly. > Up until now, I always hoped that Koha would one day be 100% MARC- > compliant -- able to understand and make use of (import, store, index, > retrieve, display and export) valid MARC data -- but I am beginning to > feel that is naive optimism on my part. I have always agreed with > Brooke's reasoning -- 'I am not paying for the fix so if the fix comes > slowly, great' -- and have been following Koha patiently for 4 years now > because of that reasoning. But there has to be hope to make waiting > worthwhile and it seems strained when the constant retort is that it > already works. Steven ... if you find a problem with the MARC support on the http://koha.liblime.com site please let me know. Thusfar, all the 'problems' you have pointed to are relics of the past and have been eliminated in 2.2.5. > Brooke is incredibly generous in excusing the failure of handling the > 650s problem. It has been almost 2 years since it was first detected. > This would be considered a fatal flaw to any commercial ILS, great > support notwithstanding. I already pointed out to you that that problem has been fixed in the latest version of Koha. > My question would be, given what Joshua has shown, for example, with the > Control Fields, when common sense demands ease of use, library science > demands the traditional access points, and when the standards as they > have emerged demand integrated access to has been deemed -- by the > relevant authorities -- core fields as a mark of compliance, WHY are > these things left to be entered in at all by the end user? (You do not > seem to take nearly the same casual attitude towards the much simpler > matters involved in acquisitions.) > > Would it not be easier, more logical and more compliant to have them > hard-wired in? If someone wants to ignore them, isn't it easier just to > have the option to delete a field from view (whether that is in a > standard view, an ISBD view or a MARC view)? (Again to take > Acquisitions, you have different modes available there: was that not a > similar kind of decision to what I am questioning?) In fact, I've hired a consultant to do just that. He's systematically setting up the MARC Frameworks to be fully compliant with Standard MARC Bibliographic Records. When he's done, the frameworks will be included in CVS and released with version 2.2.6 of Koha. > I don't think, Brooke, you should fear being burned at the stake for > your assessment of Koha's library type focus. I think what you said is > both remarkably honest and completely accurate. I guess I just hoped > that Koha would be expanding its domain rather than concentrating. We're definitely aiming high with Zebra. I fully intend to have Koha up-and-running in large public and academic libraries in the near future. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0