- Koha - lists.katipo.co.nz

More MARC development
by Tonnesen Steve 18 Jun '01

18 Jun '01

My MARC editor has come a little farther along. It is now possible to add new fields and subfields, edit existing subfield values, and delete subfield entries. Still to be done: - the interface needs some major improvements - the code needs to be broken down into modules of some sort. - no way to add a subfield if all of the existing subfields are deleted... workaround is probably to delete the tag when the last subfield is deleted, so that the tag has to be recreated with an initial subfield. - Lots of work actually tying this code into Koha somehow. This includes running alongside the existing database layout, as well as tying into things like catalogue searching, etc. - Setting up standard locations for Koha data that may not be covered by MARC (ie withdrawn, lost, itemtype). I've parsed all of the MARC21 field and subfield descriptions so they all show up in the interface as well. I gather that this is the part that will likely change in different versions of MARC though? It would be fairly simple to modify the field and subfield definitions based on a preference setting for the version of MARC (MARC21, UKMARC, NZMARC, MARSMARC, etc.). Note that the data on my test site is free to edit and play with. It's actually running on my laptop, and is a copy of a library's data. Wreck it at your leisure, I can restore it quickly if it gets really bad. :) Demo is at: http://142.28.224.11/cgi-bin/koha/acqui.simple/viewmarc.pl Steve.

2 1

Text based front end
by Nicholas Stephen Rosasco 18 Jun '01

18 Jun '01

A few months/weeks ago I randomly asked who would be interested in a text front end for the user side/opac, and someone saved me from creating more code work by suggesting the use of a text based WWW browser. I don't know how many of you have used "lynx", which is nice and available for free (lynx.browser.org) or links (http://artax.karlin.mff.cuni.cz/~mikulas/links/) which is a bit simpler. both would server well-- particularly if you have color screen on your terminals. Nick

2 1

Beginning of Marc support
by Tonnesen Steve 14 Jun '01

14 Jun '01

http://142.28.224.11/cgi-bin/koha/acqui.simple/viewmarc.pl Pretty rudimentary so far. Can add a single new field, checks if non-repeatable tags already exist. No edit feature, no ability to add extra subfields. Steve.

1 0

Re: marc and stuff!
by Tonnesen Steve 07 Jun '01

07 Jun '01

On Wed, 23 May 2001, Chris Cormack wrote: > > we may be at that point someday ... I guess the biggest question > > is how to load the marc records into the database can you point me > > somewhere for this? > > thanks for all the advise! And I love the way the software works.... > > > Ok Steve Tonnessen who is on this list has been working on this and I think > he has a working marc importer running. > Ill cc him in this reply. I have a couple of schools who have been downloading marc records for their books and importing then one at a time. They check my automatic conversion of the marc records and make whatever modifications they need. Since the site they have been getting marc records from is Canadian, they have needed to modify the ISBN to the canadian publication's ISBN in every case anyway. I've also started working on Z39.50 support. Just signed the contract for access to the National Library of Canada's Z39.50 services today. I've got a perl module called Zeta working for Z39.50 searches, but it only seems to return SUTRS format (unstructured text) and not MARC format results. It seems that Net::Z3950 is a better module, but I haven't got it working yet. Also the YAZ toolkit also has a perl-based Z39.50 server that would really be nice to tie into Koha. LCCN should not be just overwritten on the dewey field, it should have a new field created for it. I guess the hitch with this is reworking the scripts for entering and editing books... Here comes some long rambling on my part... I think Koha really needs to be moved to a system that is at least partly based on Marc. I think that the records for each bibliography should be in MARC format, and that changes can be made either to the Koha Mysql tables, or the underlying MARC records and changes will be made in both places. The way that Koha stores records currently (broken into biblio and biblioitems) might make this a little difficult, but we could maybe associate particular MARC records with biblioitems, I guess, and then just have groups of MARC records associated with one biblio, as is done now. I'm thinking maybe about having one module that is used for modifying records. Something like: modifybibitem($env, $bibitemnumber, "author=Doe, Jane"); would change the author for biblioitem $bibitemnumber to Jane Doe. The modifybibitem routine would be responsible for modifying both the MARC record, and the MySQL tables. This all gets a little tricky when you consider that the MARC record stores a fair amount more information than the MySQL tables, for example, if a particular MARC record has a subject added entry like: 650 a Extinct animals x Encyclopedias, Juvenile. The corresponding entry in the MySQL bibliosubjects table would be: Extinct animals -- Encyclopedias, Juvenile Now if I edit the bibliosubjects entry to read: Extinct animals -- Encyclopedias It would be difficult to determine how to modify the MARC record automatically in a generic way. If the entry was changed to: Extinct animals -- dinosaurs It becomes even more difficult to incorporate the change back into the MARC record. I suppose the web interface could pop up a form saying something like, --- Need more information for MARC record modification: 650 a Extinct animals __ Encyclopedias --- with an 'x' as a suggestion for the text entry box. Steve Tonnesen Coast Mountains School District

5 6

Net::Z3950 module
by Tonnesen Steve 01 Jun '01

01 Jun '01

Anybody here have any experience with the perl Net::Z3950 module? I've got it doing successful searches of the National Library of Canada, but I can't figure out how to get raw MARC results out of it. I can get GRS1 results, or structured text results no problem, but I can't get MARC for some reason. When I use: print Net::Z3950::Record::USMARC::render($rec); I get the following error: Can't call method "output" on an undefined value at /usr/local/lib/site_perl/i386-linux/Net/Z3950/Record.pm line 236. Steve.

1 0

Linux...but WHICH Linix!
by COURYHOUSE＠aol.com 29 May '01

29 May '01

Good morning Folks! OK found an old Corel LINUX CD, loaded up one of the systems, have it on the network and talking, but I would like to hear from some of the other users out there which distribution of LINUX they have had the most luck with. Any input is great! thanks Ed Sharpe archivist for SMECC

1 0

Re: FW: [Koha] Re: marc and stuff!
by COURYHOUSE＠aol.com 27 May '01

27 May '01

> Subj: Re: FW: [Koha] Re: marc and stuff! > Date: 5/26/01 10:29:09 PM US Mountain Standard Time > From: <A HREF="mailto:COURYHOUSE">COURYHOUSE</A> > To: <A HREF="mailto:chris@katipo.co.nz">chris(a)katipo.co.nz</A> > > > > You may want to check or perhaps others here can enlighten us as to haw > this is handled by some of the commercial packages.... > > UPDATE!!! the 733 MHz machine was purchased today and windows will be > stripped from the drive and LINUX installed! > > will be using the caldera LINUX 2.4 edesk > > Any comments? Can always change.... > > Ed Sharpe > > > >> Subj: Re: FW: [Koha] Re: marc and stuff! >> Date: 5/25/01 2:54:18 PM US Mountain Standard Time >> From: chris(a)katipo.co.nz (Chris Cormack) >> Sender: koha-admin(a)lists.katipo.co.nz >> To: koha(a)lists.katipo.co.nz >> >> >> >> >> On Fri, May 25, 2001 at 05:16:06PM -0400, COURYHOUSE(a)aol.com said: >> > preference would of course be to also store them in MARC as well but >> one >> > thing at a time! >> > >> > ed >> >> Hi Ed >> >> Forgive me if im wrong, and please correct me if I am, but Im not sure why >> its >> nessecary to store things in MARC. A MARC file AFAIK is just a sequential >> file that follows a set format. >> Having the format set allows the file to be transferred between systems >> that >> understand that format. >> I dont see why it is nessecary to store the data as a sequential file, if >> you have some easy routines that can a) easily parse said file and store it >> in our database and b) can retrieve information from our database and >> create >> a MARC record from it. >> >> >From what I gather the main things the Library of Congress looks for when >> assesing MARC 21 compatibility is that the system loads in the full record >> with no false or arbitritary limitations on such thing as the length of the >> notes field, or the number of subject headings. And that the system allows >> for the records to be written back in MARC 21 communications format. >> >> Of course it may well work out, that these two aims are very hard to >> achieve >> without storing them in MARC format, then again it may not. >> >> Just thinking aloud really >> >> Chris >> -- >> Chris Cormack >> Programmer >> 025 500 789 Katipo Communications >> Ltd >> chris(a)katipo.co.nz >> www.katipo.co.nz >> _______________________________________________ >> Koha mailing list >> Koha(a)lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> >> >> >> > > >

1 0

Re: FW: [Koha] Re: marc and stuff!
by Chris Cormack 25 May '01

25 May '01

On Fri, May 25, 2001 at 05:16:06PM -0400, COURYHOUSE(a)aol.com said: > preference would of course be to also store them in MARC as well but one > thing at a time! > > ed Hi Ed Forgive me if im wrong, and please correct me if I am, but Im not sure why its nessecary to store things in MARC. A MARC file AFAIK is just a sequential file that follows a set format. Having the format set allows the file to be transferred between systems that understand that format. I dont see why it is nessecary to store the data as a sequential file, if you have some easy routines that can a) easily parse said file and store it in our database and b) can retrieve information from our database and create a MARC record from it. # From what I gather the main things the Library of Congress looks for when assesing MARC 21 compatibility is that the system loads in the full record with no false or arbitritary limitations on such thing as the length of the notes field, or the number of subject headings. And that the system allows for the records to be written back in MARC 21 communications format. Of course it may well work out, that these two aims are very hard to achieve without storing them in MARC format, then again it may not. Just thinking aloud really Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz

1 0

FW: [Koha] Re: marc and stuff!
by jmulford＠legionaries.org 25 May '01

25 May '01

Friends, Greetings from Rome, Italy! This is my first post to the list. I'm a member of a consortium of 16 Universities in Rome with all our libraries containing a little over 2,000,000 volumes. Most have been using Aleph300 for the past 10 years and are seriously considering switching to AMICUS (used by British Library, Australian & Canadian National Systems, etc.) but I recently came across the Koha Proyect and have been impressed. Have you had any other requests from Italy? How about Spain or Mexico where we have other campuses? If I can get support from our programmers here, maybe we could help to port the program into Italian. Nevertheless, we would definitely need MARC and z39.50 support to win over the full consortium of libraries. With a little support, we might even be able to help you develop those modules, but I need to know what it might entail or if work has already been done on it. I spent a few hours reading ALL the past mailing list postings and see some interesting things developing. I did see several references to MARC.pm and z39.50 but they seemed merely as comments and no commitment from anyone on the list or beyond. O.K. Make my day (or maybe night in N.Z.) and tell me that MARC and z39.50 standards are on the (near) future wish list. I would just LOVE for our university (www.upra.org) to spearhead this project here in Italy but need some help from our friends down under. P.S.: I'm not a programmer just a hacker and admirer of things Linux, but I do sign the checks of our programmers, so I guess that helps. James Mulford Director of Finance & Development Regina Apostolorum University Rome, Italy -----Original Message----- From: Nicholas Stephen Rosasco [mailto:nsr4n@tetra.mail.virginia.edu] Sent: venerdì 25 maggio 2001 18.39 To: koha(a)lists.katipo.co.nz Subject: Re: [Koha] Re: marc and stuff! While we're (on list, at least) considering possible major-code-change wishlists, is there anything else :) anyone wants? Also, would anyone consider addition of a text based front end for users a valid item? I know there is a text based front end for the library staff... but a text front end would permit use of serial terminals. I think it may be possible to create a linux boot+install-config floppy, and a cheat sheet for answering questions for install, thereby getting us closer to a turnkey system. Or is having a linux person on hand still a better idea at the moment? Thoughts? Nick _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

2 1

RE: [Koha] Re: marc and stuff!
by Lora Morgaine 25 May '01

25 May '01

Hi everyone, I've been lurking on this list for a while but would like to put in my two cents. I work for a non-profit organization called the Technology Resource Center, based in Seattle, Washington. We try to find ways to help alleviate the digital divide, and are very involved in libraries in the USA and in Latin America. A small group of us have been working on making KOHA compatible with MARC records and in general with libraries in North and South America. We are at the point where we successfully import MARC records in full, and allow editing on over 200 most-utilized fields and subfields. One can also create a new MARC record, but cannot export records yet. We also altered the database structure significantly to import successfully all fields, subfields, and indicators, and also changed the OPAC interface. It was rewritten in PHP for more flexibility, as well. Because we have changed so much of the system, we renamed ours to "OpenBook" - but it's still an open-source system with code available to everyone. Our ultimate goal is to help small libraries who wish to automate or move to less expensive automation options. Now, that said, it's not quite ready yet for public input and troubleshooting. We will be ready for beta testing as of the US ALA convention, on June 15 2001. I can send the link to the OPAC to anyone who wants to try that out though. It does have problems still, we know, and we're working on them. If you have questions or etc, please let me know. We give full credit to the folks in New Zealand - without their structure this never would have come to completion! We just hoped to change it for the N. American MARC standards in cataloging, and change the OPAC to be more like US-based OPACs. Right now, we only have OPAC and cataloging modules done. Circulation will be forthcoming around September, possibly a bit later. I hope that the members of this list will be interested in trying out the OPAC and doing testing on cataloging for us... Sincerely, Lora Morgaine TRC

4 3