- Koha - lists.katipo.co.nz

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

Re: [Koha] Help-Dewey displays as 99.999 for most entries
by Olaf Clausen 23 Feb '06

23 Feb '06

Hi Steven, Thanks for your help. I connected to the DB and had a look at the records. It seems that all the entries are either 99.999999 or 0 in the 'dewey' field of 'biblioitems' but the 'subclass' field holds valid entries ie. LOW or VER etc. If I add a new biblio item within the catalogue section of Koha and assign a dewey of 123.45 and subclass of CLA for example the new record in biblioitems ends up with a dewey of 99.999999 and subclass CLA. Any ideas? Furthermore, when I try to edit a biblio there is no field for dewey or subclass. I just get the numbers 0,1,2,3 down the side and a few marc tags but nothing that would be appropriate for dewey. Incidentally, if I add a new biblio and then edit it, I get the numbers 0-9 down the side but most of the sections are blank. Thanks again for your help. Olaf Clausen Fountainview Academy Lillooet, BC Canada --------------------------------------------------------------------------------------------- Thursday, February 23, 2006 01:21 CST Hi, Olaf, A quick and provisional response to your letter ... IIRC, the version of Koha you referred to using is pre-MARC. It is important that you discover where that Dewey call number info is stored. For some of those 2600 records where another Dewey number (other than the obviously incorrect 99.999) is reported, can you see a difference in the record structure that you could imitate? You should probably ignore the 852 for now (unless that is somehow where you have your Dewey call numbers stored). Yes, 082 holds an assigned Dewey call number. The call number that your library chooses to use can be held elsewhere and that is an intended function of the 852. I don't understand why/how only the 852 $k would be editable. The simplest thing would probably be to get the call numbers you want to use moved (mirrored, copied, whatever) to the MARC 942 $k (which will hold Dewey numbers). You will also need to code the 952 properly so that there will be barcodes attached to the actual items. For more complete and useful information, please do take a look at Stephen Hedges' Koha Documentation page and his User's Guide and Brooke's Newbie guide there. Surf to URL <http://www.kohadocs.org> Hopefully this will get you started in the right direction. Best of luck! Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada ============================================================ From: Olaf Clausen <olafpc(a)yahoo.ca> Date: 2006/02/22 Wed PM 06:34:08 CST To: koha(a)lists.katipo.co.nz Subject: [Koha] Help-Dewey displays as 99.999 for most entries Hello, I'm fairly new to Koha having tried it out several years ago. At that time we had a student enter our books into Koha 1.2.3. For various reasons we had to shelve the project but we were able to enter about 3000 books into the system. I am once again trying to get Koha working for our small high school and have installed Koha 2.2.4 on a Fedora Core 4 box and imported the old database from 1.2.3. All the items show up fine but the dewey field in searches is the same for almost all books (2600 of them report 99.9999) and the remainder report another dewey number. I know nothing about MARC and am struggling to find out were the dewey information can be changed. In reading the user guides and posts, it seems to me that MARC tag 082a is supposed to hold this data but only tag 852k is editable and it doesn't seem to allow anything but two letters to be entered. Furthermore, search results show a Dewey field but no location/call number field (ie 852)--so what does 852 do anyway? Simpler is better for our little library so straight Dewey would work better for us. Can anyone help me figure out how to access and change the Dewey field for each item? Thanks, Olaf Clausen Fountainview Academy --------------------------------- Find your next car at Yahoo! Canada Autos

1 0

Re: [Koha] marc import
by BWS Johnson 23 Feb '06

23 Feb '06

Salve! >I don't understand why people think Koha is somehow deficient in MARC >support. (Most of the "problems" I've seen are a result of not reading >the manual!) When I got my MLS, I was taught that MARC is a way to store, >retrieve and share records between libraries. I don't remember a single >word being said about how the records are displayed or manipulated by an >ILS. If you can save, edit, and search on all valid MARC fields, then you >have full MARC support. Since Koha can do exactly that when it's set up >properly (as well as importing and exporting MARC records), then Koha has >full MARC support. Period. > The 650 x problem is a big deal. Other than that, I agree. Now, if there is a way to make the subject subheadings play nice with their bigger brothers, let me know. I do like the keyword search - it blows other ILSs out of the water. Much of this falls under "save the time of the reader" to me. >NPL has been using Koha for 29 months now, and we haven't had any unusual >problems with any of our MARC records. To imply that Koha is somehow >"MARC-deficient" may work in the hallowed halls of theory, but in the real >world of day-to-day library operations, it's just not true. > I generally tell people that most librarians wouldn't notice, and almost all users won't. To me, it boils down to this: I'm not paying for the fix, so if the fix comes slowly, great. As it is, the support with Koha is way better than commercial products. Frankly, and I know I'll get burned at the stake for this, Koha was really meant as a small to medium public library product in a nation that couldn't give a fig about MARC. Having perfect MARC compatibility is an academic or medium to large library problem. >Someday soon, when all of the rest of the world is using XML and only a >few of us MLS folks still give a damn about MARC, I expect to see Koha as >one of the few ILS's that is flexible enough to still survive. This I wholeheartedly agree on. How I already grin at the thought of being able to easily link my ebooks! It's awesome that Koha was all set to do this. Cheers, Brooke @ Hinsdale MA

1 0