- Koha - lists.katipo.co.nz

Re: [Koha] MARC TODO list
by COURYHOUSE＠aol.com 25 Jun '01

25 Jun '01

Remember some of us will use LC rather than Dewey, especially those in the scientific library field..... Ed > Subj: [Koha] MARC TODO list > Date: 6/25/01 1:18:42 PM US Mountain Standard Time > From: tonnesen(a)cmsd.bc.ca (Tonnesen Steve) > Sender: koha-admin(a)lists.katipo.co.nz > To: koha(a)lists.katipo.co.nz (Koha Open Source Library System) > > > > > > I've generated a short TODO list for adding MARC support to Koha below. > I've also checked most of my files into CVS now. I've placed most of them > in the koha/marc/ subdirectory, but the koha/C4/Catalogue.pm file is also > required to convert existing koha records to marc format. > > Please do not use any of this on production systems yet! > > > > TODO list > > 1. Finish cataloguing api (Catalogue.pm) > > 2. Modify existing code to use the new cataloguing api > a. start with all write routines > b. then all read routines > > 3. Polish up MARC editor. Must include some sanity checks to prevent > modifications with the MARC editor rendering the data unusable by > Koha. > a. don't delete the barcode, warning before modifying barcode > b. don't mess up linkages between 852 and 876 tags > c. Home branch and holding branch info should require warnings before > updating. > d. others? > > 4. Need to create some indexes of the MARC data to aid in searches. > Soundex searches would be nice. > a. subject index > b. title index > c. author index > d. dewey index > e. itemtype index > f. soundex indexes would require an index with 1 word in each record. > For example, a book with the title "The Habitat and Lifestyle of the > Elephant" would have entries for "Habitat", "Lifestyle" and > "Elephant" all pointing to the book's record. An sql query like > "select Record_ID from soundex_index where soundex(word) like > soundex('elefant')" would return a point to "The Habitat and > Lifestyle of the Elephant". (Personally, I think this is pretty > silly, but I had some librarians ask for it, and it isn't overly > difficult to implement). Soundex searches should be configurable as > an option somewhere. For example, have a special interface for young > children where they just type in a word and hit enter and soundex > searches are used, but normal searches do not use soundex. It would > be annoying for titles with the words 'Rode' and 'Road' to show up > when you search for 'Rhode', for example. > > 5. A million other things, probably... > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

MARC TODO list
by Tonnesen Steve 25 Jun '01

25 Jun '01

I've generated a short TODO list for adding MARC support to Koha below. I've also checked most of my files into CVS now. I've placed most of them in the koha/marc/ subdirectory, but the koha/C4/Catalogue.pm file is also required to convert existing koha records to marc format. Please do not use any of this on production systems yet! TODO list 1. Finish cataloguing api (Catalogue.pm) 2. Modify existing code to use the new cataloguing api a. start with all write routines b. then all read routines 3. Polish up MARC editor. Must include some sanity checks to prevent modifications with the MARC editor rendering the data unusable by Koha. a. don't delete the barcode, warning before modifying barcode b. don't mess up linkages between 852 and 876 tags c. Home branch and holding branch info should require warnings before updating. d. others? 4. Need to create some indexes of the MARC data to aid in searches. Soundex searches would be nice. a. subject index b. title index c. author index d. dewey index e. itemtype index f. soundex indexes would require an index with 1 word in each record. For example, a book with the title "The Habitat and Lifestyle of the Elephant" would have entries for "Habitat", "Lifestyle" and "Elephant" all pointing to the book's record. An sql query like "select Record_ID from soundex_index where soundex(word) like soundex('elefant')" would return a point to "The Habitat and Lifestyle of the Elephant". (Personally, I think this is pretty silly, but I had some librarians ask for it, and it isn't overly difficult to implement). Soundex searches should be configurable as an option somewhere. For example, have a special interface for young children where they just type in a word and hit enter and soundex searches are used, but normal searches do not use soundex. It would be annoying for titles with the words 'Rode' and 'Road' to show up when you search for 'Rhode', for example. 5. A million other things, probably...

1 0

MARC
by Tonnesen Steve 25 Jun '01

25 Jun '01

I've now got a pretty basic MARC converter built that will take all existing records in the biblio, biblioitems, items tables and convert them to MARC records. I stuck pretty much with the mapping I sent in my previous post, since nobody pointed out any glaring errors. Item holdings information is stored in tags 852 and 876 with a linkage number in subfield 8 to tie the two tags together. http://142.28.224.11/cgi-bin/koha/acqui.simple/viewmarc.pl will now point you to record 221 by default which has 6 items. This converter uses the beginnings of a Catalogue.pm module that I'm working on. The newBiblioItem() and newItem() subroutines are fairly complete for the MARC side. The Koha side should be much easier to write. Steve.

3 5

i18n of koha - progress report
by Benedykt P. Barszcz 23 Jun '01

23 Jun '01

Hi, Actually I should not be writing this. I have convinced a friend of mine to look at koha project and try to internationalize it. What he did was he wrote a simple perl script that makes it possible to switch between languages in koha by simply setting the language preference in your browser. For that to work an "Action" directive is to be set in Apache, like so: Action text/html /cgi-bin/koha/trans.pl Action text/plain /cgi-bin/trans.pl The "trans.pl" script does the whole magic to present the language of your preference of your browser. Requirements: gettext.pm, translated koha.pot file, and compiled with msgfmt. Now I need to convince him to subscribe to this mailing list to contribute:-) It may take some time. But the thing works and I am amazed.... Benedykt PS. Aha, he also did something to the koha perl scripts so perl variables can be correctly interpreted by HTML. -- Chcialbys zarobic lub "dorobic" naprawde dobre pieniadze? Otrzymasz do 300zl za kazda firme ktora wprowadzisz do Centrum e-biznesu Poszukaj wsrod znajomych, znajdz firme i wypelnij z nia prosty formularz Aby rozpoczac wejdz do http://praca.getin.pl i zostan Partnerem Getin

2 1

miniBib
by Benedykt P. Barszcz 23 Jun '01

23 Jun '01

http://minibib.sourceforge.net/ I wonder what they are up to? They say that tomorrow a first stable version might be released.... Here is what the sourceforge description says: miniBib is a graduate project written in Java and object oriented. miniBib aim to help the management of a library Benedict -- Chcialbys zarobic lub "dorobic" naprawde dobre pieniadze? Otrzymasz do 300zl za kazda firme ktora wprowadzisz do Centrum e-biznesu Poszukaj wsrod znajomych, znajdz firme i wypelnij z nia prosty formularz Aby rozpoczac wejdz do http://praca.getin.pl i zostan Partnerem Getin

1 0

MARC info request from librarians
by Tonnesen Steve 21 Jun '01

21 Jun '01

Here's a question for the librarians in the crowd. I'm trying to match up the data in Koha's biblio, biblioitems, and items tables to MARC tags and subfields. Can you go over the list below and comment on my mapping, both things you think I've done wrong, or things that I'm missing entirely? Thanks for the help, Steve. ========================================================================= Koha to MARC field mapping ========================================================================= # From biblio table: title 245 a subtitle 245 b unititle 246 a ??? serial seriestitle 440 a copyrightdate 245 f (or g?) and what is the format? notes 500 a (maybe set $3 to 'biblio'?) author 100 a,b,c,d additional author 700 a,b,c,d (set $e to 'author') subject 650 a # From biblioitems table: volume 440 v number 440 n classification (I'm not sure this is used in Koha anymore?) itemtype 852 k (call number prefix) isbn 020 a issn 022 a dewey 082 a subclass 852 m (call number suffix) place 260 a (Place of publication) publishercode 260 b (Name of publisher, distributor) publicationyear 260 c (Date of Publication) volumedata volumeddesc illus 700 a,b,c,d (set $e to 'illustrator') pages 300 a size 300 c notes 500 a (maybe set $3 to 'biblioitems'?) lccn 010 a # From items table: barcode 852 p dateaccessioned 876 d (date acquired) booksellerid 876 e homebranch 852 holdingbranch 876 l (temporary location) price 876 c (cost) replacementprice 876 c? (cost) replacementpricedate 876 d? (date acquired) datelastborrowed datelastseen multivolume stack notforloan 506 or 876 h itemlost 876 j (item status) wthdrawn 876 j (item status) bulk issues renewals reserves restricted 506 a restrictions on access for all items, or 876 h for item specific restrictions? binding itemnotes 876 z (public note) 876 x (nonpublic note) interim =========================================================================

2 2

Ramblings on a Catalogue API
by Tonnesen Steve 20 Jun '01

20 Jun '01

More technical mumbo jumbo. I'm thinking the new Catalogue API should have two interfaces: one that is modelled on the biblio,biblioitems,items table and one that is modeled on the MARC data. Here are my ramblings on the first interface, which would need to be implemented first anyway. Adding a new item: Create a $item object: $item->{'biblioitemnumber'}=xxxx; $item->{'barcode'}=xxxxx; . . . dateaccessioned=xxxxx; booksellerid=xxxxxx; homebranch=xxxxxxx; price= replacementprice= replacementpricedate= notforloan= restricted= holdingbranch= itemnotes= Call Catalogue->AddItem($env, $item) The AddItem subroutine can insert the data into a new items record as before, as well as: Grab the MARC Record_ID number from the biblioitems table for biblioitemnumber given in the $item object and add an 852 tag for the new item in the MARC record. We still have to work out where in the 852 tag the different bits of information will be stored, or if some information maybe should be stored elsewhere, like in 859 (any tag, subfield, or indicator with a 9 in it is a local implementation). Catalogue->UpdateItem($env, $item) could be used to modify an existing item. The $item object in this case would also have to have an itemnumber. The MARC side could grab the barcode from the items table to find the corresponding 852 entry in the MARC record. Catalogue->AddBiblioitem($env, $biblioitem) $biblioitem->{'biblionumber'}=xxxx; volume= number= classification= itemtype= isbn= dewey= subclass= etc. Again, this would add an entry to the biblioitems table, and create a new MARC record. The Record_ID value from the newly created MARC record would also be inserted into the new biblioitems record in a new Record_ID field. Catalogue->UpdateBiblioitem($env, $biblioitem) Same idea as UpdateItem... Catalogue->AddBiblio($env, $biblio) Catalogue->UpdateBiblio($env, $biblio) These two subroutines have no counterpart in the MARC side. The data contained in the biblio table is stored in the MARC record for each of the corresponding biblioitems. All of the MARC records associated with a given biblio would have a unique id (same as the biblionumber) stored somewhere in the MARC record, location still to be determined. I'm not sure at the moment how many places in the existing Koha code will have to be modified to use this new API. All over the acquisitions code, for sure, as well as the catalogue editing code. Any other places that need looking at? Any spots in the code where updates may not fit with my proposed API here? Reading subroutines would be similar to the writing subroutines: Catalogue->GetBiblio($env, $biblionumber); Catalogue->GetBiblioitem($env, $biblioitemnumber); Catalogue->GetItem($env, $itemnumber); something like that. These three subroutines would _always_ read from the MARC record data. This will be more difficult than the current setup which just grabs the entire row from an SQL select statement and returns the result as the object, but it ensures that there is a single authoritative data source and allows for the eventual removal of the biblio, biblioitems and items tables once their functionality is completely met by the MARC records. These subroutines, specifically the GetBiblioitem and GetItem would also return some structured MARC data: 1: a full MARC record, 2: a text structured MARC record, 3: an HTML formatted MARC record. Steve.

1 0

MARC Support
by Tonnesen Steve 20 Jun '01

20 Jun '01

I never realized what a hassle it is to sort lists where numbers come after letters (as is the norm with MARC subfield marks). MySQL will only sort with numbers before the letters. I've managed to get the MARC records sorting in the right order now, and it can optionally display both tag names and subfield names for those of us for whom MARC is somewhat greek. When adding new subfields, there is a drop down box with subfield marks and names, or a simple text entry box where you can just type in the subfield mark. Now I really need to start thinking about how to tie this in to Koha. I don't think it should be too difficult to generate MARC records from the existing biblio, biblioitems, items table data. I suppose the easiest thing to do would be to insert some kind of API everywhere that modifies those tables so that they also modify the MARC records. This would be a first step towards adding MARC support. Second step would be inserting an API for every routine that _reads_ from those tables. At that point, all reads could gather data from the MARC records, and all writes could update both the old tables and the new MARC tables. MARC records would be linked at the biblioitems level. The items table data would, I believe, mostly be recorded in an 852 - Location tag in the Marc data. Links to the biblio table could be stored in a local 9XX tag. For example, if there is a biblio entry for "King Lear" with biblionumber 5214, and there are 4 biblioitems for that biblio (hardcover, paberback, cassette, large print), the MARC records for each of those four would have a tag like: 944 ## a 5214 When doing searches on MARC records, all four results with the same 944 a value could be lumped together under "King Lear" in the results output. I believe this would result in the same behaviour obtained with the three split tables? ------------------------ Technical Stuff Below!!! ------------------------ Rough outline of the Schema I used: I used the schema developed for the Pytheas project. It is fully capable of storing all of the information in any MARC record, and is not overly difficult to search. One feature I'd like to add is a keyword index so that soundex searches would work (ie soundex(elefant) = soundex(elephant)). The Resource_Table contains an entry for every MARC record. Resource_Table Resource_ID int auto_increment Record_ID int The Bib_Table contains an entry for every tag in a record. The Record_ID is used to link all tags in a MARC record together. Each entry in Bib_Table will have one of the Tag_#XX_ID fields filled out with a number that links to the appropriate #XX_Tag_Table. The Control_ID field links to a Control_Table that is used for the fixed length data elements like 008. Bib_Table Bib_ID int auto_increment Record_ID int Tag_0XX_ID int Tag_1XX_ID int Tag_2XX_ID int Tag_3XX_ID int Tag_4XX_ID int Tag_5XX_ID int Tag_6XX_ID int Tag_7XX_ID int Tag_8XX_ID int Tag_9XX_ID int Control_ID int The 2XX_Tag_Table is representative of 10 tables (0XX_Tag_Table through 9XX_Tag_Table). It contains one entry for each tag of a record. The Tag_ID value is linked back to the Bib_Table Tag_2XX_ID field. The Subfield_ID is used to link to the 2XX_Subfield_Table which contains all of the subfields for this tag. 2XX_Tag_Table Tag_Key int auto_increment Tag_ID int Indicator1 int Indicator2 int Tag char(3) Subfield_ID int The 2XX_Subfield_Table is again representative of 10 such tables. The Subfield_ID is used to link all of the subfields of a given tag together and back to the 2XX_Tag_Table entry. Small values can be stored directly in the Subfield_Value field. Larger values are stored in separate blob tables using the Storage_ID field as the link. 2XX_Subfield_Table Subfield_Key int auto_increment Subfield_ID int Subfield_Mark char(1) Subfield_Value char(255) Storage_ID int The Storage_Table and *Blob_Table is where the data elements themselves are stored. Depending on the size of the data, they can be stored in the Blob_Table, Med_Blob_Table, or the Long_Blob_Table, based on the value of Storage_Type. Storage_Table Storage_Key int auto_increment Storage_ID int Blob_ID int Med_Blob_ID int Long_Blob_ID int Storage_Type enum('B', 'MB', 'LB'); The Med_Blob_Table and Long_Blob_Table are identical to Blob_Table except that the Blob_Data field is mediumblob or longblob respectively. The Seq_No field can be used to break a huge record into multiple longblob's if necessary. Blob_Table Blob_Key int auto_increment Blob_ID int Blob_Data blob Seq_No int If I wanted to find the title and author of all records that had "bear" in any subject (6XX) tag, I would use: select B.Record_ID from Bib_Table B, 6XX_Tag_Table T, 6XX_Subfield_Table S where B.Tag_6XX_ID=T.Tag_ID and T.Subfield_ID=S.Subfield_ID and S.Subfield_Mark='a' and S.Subfield_Value like '%bear%'; for each Record_ID returned, run the following to get the author: select S.Subfield_Value from Bib_Table B, 1XX_Tag_Table T, 1XX_Subfield_Table S where B.Record_ID=$Record_ID and B.Tag_1XX_ID=T.Tag_ID and T.Subfield_ID=S.Subfield_ID and T.Tag='100'; and the following to get the title: select S.Subfield_Value from Bib_Table B, 2XX_Tag_Table T, 2XX_Subfield_Table S where B.Record_ID=$Record_ID and B.Tag_2XX_ID=T.Tag_ID and T.Subfield_ID=S.Subfield_ID and T.Tag='245';

1 0

Re: [Koha] More MARC development
by COURYHOUSE＠aol.com 19 Jun '01

19 Jun '01

Hi Steve! Looks neat keep up the good work! Sounds like the open source meeting AT ALA in SF calif. USA was real interesting here is what was there...... I was not able to make it but Bette Sharpe did attend and will be bringing me back a stash of whatever she could grab.... Ed Sharpe LITA Open Source Systems Interest Group Program: "Web Tools and Digital Resources: Open Source Then and Now" Sunday, June 17, 2001, 8:30am-10:30am Marriot Golden Gate Section B Access and services that libraries provide is often limited by the software and services that they are able to purchase. But an alternative--freely-available open source software--is available to help libraries improve and shape services and better meet users' needs. But how can librarians get involved in development of these products and contribute to the process? This program features open source developers discussing their projects: Larry Wall and PERL, Eric Lease Morgan and <A HREF="mailto:MyLibrary@NCState">MyLibrary@NCState</A>, and Willem Schulton with projects in rural public libraries. Speakers: 1. Willem Scholten, Executive Director, Waitt Family Foundation Technology Resource Center, Seattle, WA 2. Eric Lease Morgan, Networked Resources Development Librarian, North Carolina State University Libraries, Raleigh, NC 27695-7111 3. Larry Wall, PERL Inventor and author, c/o O'Reilly & Associates, Sebastopol, CA 95472 > Subj: [Koha] More MARC development > Date: 6/18/01 12:38:42 PM US Mountain Standard Time > From: tonnesen(a)cmsd.bc.ca (Tonnesen Steve) > Sender: koha-admin(a)lists.katipo.co.nz > Reply-to: <A HREF="mailto:tonnesen@cmsd.bc.ca">tonnesen(a)cmsd.bc.ca</A> (Tonnesen Steve) > To: koha(a)lists.katipo.co.nz (Koha Open Source Library System) > > > > > > 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 > > >

2 1

Re: [Koha] Text based front end
by COURYHOUSE＠aol.com 18 Jun '01

18 Jun '01

as I remember it can run on the linux server as well as the opac and in theory you could hook vt 100 type terminals to it. most companies throw these old terminals away! thus using less pc's and perhaps having a little better security. Ed Sharpe archivist for SMECC > Subj: [Koha] Text based front end > Date: 6/18/01 12:41:38 PM US Mountain Standard Time > From: nsr4n(a)tetra.mail.virginia.edu (Nicholas Stephen Rosasco) > Sender: koha-admin(a)lists.katipo.co.nz > To: koha(a)lists.katipo.co.nz > > > > > 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. > >

1 0