- Koha - lists.katipo.co.nz

Record doesn't exists on V2.0.0
by rahayu rms 26 Jul '03

26 Jul '03

Hi.. I have try upload marc record using data from OCLC using extension file .dat and .bib. Statement shows that the records are imported.When I checked the record in biblio table, the record does not exists.Am I wrong or maybe something to do? Anybody can tell me and explain how to upload the record? I am using koha v2.0.0 on windows.. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

RE: [Koha] data import question - a few more thoughts
by baljkas＠mb.sympatico.ca 25 Jul '03

25 Jul '03

Friday, July 25, 2003 14:22 CDT David, Thank you for the very helpful rejoinder. I plead guilty to going with what was familiar to me. In all honesty, working with the few systems that I have, I'd never seen the holdings fields used and so hadn't looked into the 876. Of course, you are right. Very neat. Thank you for pointing all of us in a better direction! The FRBR stuff is also something I've yet to get into as keeping up with MARC has always seemed enough of a challenge. ;-) Thanks again, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB CANADA see P.S. below "Bigwood, David" <Bigwood(a)lpi.usra.edu> wrote: >Steven, > >Most of this I agree with 100%. Well said, it deserves better >distribution. > >However putting copy information into 037 is not the way I'd go. It is >not easy to distinguish the different information for different copies >there. Also, if we take a FRBR approach 037 seems to apply to the >expression but acquisition information belongs at the item level. P.S. when I'd used it that way, David, I'd taken advantage of its repeatability and the note fields to clarify the relationship of the price to the item level; nevertheless, you are right in what you say in recommending the 876. >Field 876 seems a better choice. That would tie the donated copy from >1999 to one item and the 1998 copy costing 45.00 from a particular fund >with another copy. > >Sincerely, >David Bigwood >bigwood(a)lpi.usra.edu >Lunar & Planetary Institute > >-----Original Message----- >From: baljkas(a)mb.sympatico.ca [mailto:baljkas@mb.sympatico.ca] >Sent: Thursday, July 24, 2003 7:51 PM >To: larry(a)larrystamm.com; koha >Cc: baljkas(a)mb.sympatico.ca >Subject: Re:[Koha] data import question - a few more thoughts > >Thursday, July 24, 2003 18:46 CDT > >Hi, Larry, > >Glad that some of what I wrote was useful. I know that the MARC stuff >isn't easy for those who haven't been 'initiated' into its mysteries. > >[major snip] Personally, I would have preferred the data to be placed >in a good old 037 tag. To my mind, its subfields provide for all of the >above, plus it can be entered at the time one creates a temporary >minimal record (to indicate to patrons searching that an item is >on-order for example) without the need to muck about with the 852 or >other call number field until the work is received in cataloguing. > >The map for the 037, is simple > $a Stock number - possibly useful for re-ordering/replacement > $b Source of stock number/acquisition ** > $c Terms of availability = (in almost all cases) price ** > $f Form of issue - easily adaptable to be an institution's needs > with a ltd. institution-specific set of terms or more ones > more generally recognised > $n Note - where you could easily enter acquisition fund (usually > coded in most institutions anyway), order date and received-in > date > >ex. 037 _ _ $bBook Barn $c$22.50 $c$5.00 (sale price) $fTrade pbk. > $nGenBkFund; ordered 20021209; received 20030108.

1 0

RE: [Koha] data import question - a few more thoughts
by Bigwood, David 25 Jul '03

25 Jul '03

Steven, Most of this I agree with 100%. Well said, it diserves better distribution. However putting copy information into 037 is not the way I'd go. It is not easy to distinguish the different information for different copies there. Also, if we take a FRBR approach 037 seems to apply to the expression but acquisition information belongs at the item level. Field 876 seems a better choice. That would tie the donated copy from 1999 to one item and the 1998 copy costing 45.00 from a particular fund with another copy. Sincerely, David Bigwood bigwood(a)lpi.usra.edu Lunar & Planetary Institute -----Original Message----- From: baljkas(a)mb.sympatico.ca [mailto:baljkas@mb.sympatico.ca] Sent: Thursday, July 24, 2003 7:51 PM To: larry(a)larrystamm.com; koha Cc: baljkas(a)mb.sympatico.ca Subject: Re:[Koha] data import question - a few more thoughts Thursday, July 24, 2003 18:46 CDT Hi, Larry, Glad that some of what I wrote was useful. I know that the MARC stuff isn't easy for those who haven't been 'initiated' into its mysteries. I snipped back some of my verbiage to make the more important parts a little more identifiable. Yes, your understanding is correct, Larry, in that 852 is "mainly" for use within an organization. However (you knew this was coming, didn't you? ;-) ) ... Part of the whole purpose of creating MARC records was the sharing of cataloguing data. LC proves this daily by giving us all free access to its records (well, one has to have the Internet, etc., etc., but that's not their fault). Part of what we're supposed to be doing, as cataloguers, is obey the conventions (AACR2R, ISBD, etc.) and the standards for use of the MARC21 system (this is why we are given examples, and for those lucky enough to work in libraries that can afford such, access to the Library of Congress Rule Interpretations, LCRIs). If sharing is going to be possible, we do have to look at how things are set up. Yes, it was arbitrary (small groups of people working mainly at LC), but it is thorough. It isn't really a good idea to start switching things around. I remember Athena very well. Especially the arguments I had with my so-called assistant over the useless entry of data like source of acquisition date, fund, price, all of which can be entered in other MARC fields properly kept out of patron's prying eyes anyway (no, I know that data isn't useless, but it can be very frustrating to try explaining to a patron why you're charging them $25 to replace a book they lost when your own catalogue says it only cost $5 [way back in 1979, of course] and I would still rather spend cataloguing time on Authority Records or at least on augmenting the collection with good 520s, genre labels and keywords to improve search results). While I admire the ingenuity of the computer-savvy in creating these wonderful systems -- and Athena is a very neat system that I quite like -- the problems it runs into are largely of its creators own making in deliberating deciding they know better than the sages of LC. When I was in grad school for history, my advisor constantly warned us students of the dangers of present-ism: 'If it's this way now, that's how it will always be, how it always was.' So, while I completely sympathise, Larry, LC-NLC have determined the usage of the field and subfields therein and it really isn't a good idea not to follow form. Who knows what developments in the future will bring? It makes it easier if we're all playing the game with the same rule book, even just for the present, let alone the future. The idea that all cataloguing is isolated from affecting others really belongs to the pre-MARC/online era. If we all follow the rules, we can all help each other out now and in the future. In the alternate mapping I suggested (and keep in mind, that's only my off-the-cuff attempt; it has no particular authority), I assumed you wanted to use the one field 852, so I just chose subfields that would allow you to do what you wanted within that one field. (BTW if the tab thing you were writing about to Derek would allow keeping the data in allowed subfields only, that would be preferable to what I suggested viz. a $d or $w.) When I was first confronted with this, I was mighty perturbed. I understand that Athena's programmers wanted to collect the data in one field: all they needed to do though was use multiple 852 $x fields! There is no reason at all for their creativity!! Following the rules would actually simplify matters. Personally, I would have preferred the data to be placed in a good old 037 tag. To my mind, its subfields provide for all of the above, plus it can be entered at the time one creates a temporary minimal record (to indicate to patrons searching that an item is on-order for example) without the need to muck about with the 852 or other call number field until the work is received in cataloguing. The map for the 037, is simple $a Stock number - possibly useful for re-ordering/replacement $b Source of stock number/acquisition ** $c Terms of availability = (in almost all cases) price ** $f Form of issue - easily adaptable to be an institution's needs with a ltd. institution-specific set of terms or more ones more generally recognised $n Note - where you could easily enter acquisition fund (usually coded in most institutions anyway), order date and received-in date ex. 037 _ _ $bBook Barn $c$22.50 $c$5.00 (sale price) $fTrade pbk. $nGenBkFund; ordered 20021209; received 20030108. Not very standardised, as you rightly hint. Or at least, not so much in the details. Core fields like the 008, 100, 245, 250, 260, 300 tend to be pretty good. But that doesn't mean we should stop trying. If it makes you feel any the better, I keep running across records in the NLC database where contributing cataloguers still aren't even following ISBD description rules for newer records (ca. 1985) and the ISBD rules, IIRC, are older than me! As a cautionary tale, let me warn you about what happened to one school division in Winnipeg. For years that division (and the one I reside and have worked in) used TKM Microcat, a decent system for when it was first created. They were told not to bother coding the 008 -- a core required field -- because that system didn't really use it (can't sort results by date, e.g. because of this). That minor reduction in labour over the years came as little comfort to the division's cheque book a few years back when all the schools had to send ALL their records for RECON because the new system they migrated to was MARC-compliant and viewed the records it was fed as the garbage they were! I kinda think LC should start gathering up a page of horror stories like this to remind folks why it is important to follow those nagging standards, even when it doesn't seem to have any purpose at the time. ;-) In any case, LC sets the structure (and it isn't completely autocratic BTW: someone at your level of authority in a library can make suggestions; my former supervisor did) and if you think it's difficult now, think what might happen if they designate something your system was using for a different purpose and many others go along with the change. Either 'welcome back to the age of splendid isolation' or See above for 'The moral of the story is ...' I would've brought you a thank-you card and cake! ;-) I agree. Plus making the patrons feel more at ease and part of the positive change, and this is of no inconsiderable value! Anyway, I hope some of what I've said this time makes sense, too, and that it may be useful to you and others. Cheers from Winnipeg, Steven F. Baljkas library tech at large Koha neophyte _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

Re:[Koha] data import question - a few more thoughts
by baljkas＠mb.sympatico.ca 25 Jul '03

25 Jul '03

Thursday, July 24, 2003 18:46 CDT Hi, Larry, Glad that some of what I wrote was useful. I know that the MARC stuff isn't easy for those who haven't been 'initiated' into its mysteries. "Larry Stamm" <larry(a)larrystamm.com> wrote: >baljkas <baljkas(a)mb.sympatico.ca> writes: > > > Just a quick addendum re: Larry Stamm's response -- [snip] > > viz. what is arbitrary in the '852'. > > > Of course, all of the structure of tags and subfields is > > arbitrary Remember to check LC's MARC documentation to see what > > fields and subfields within fields are defined and how they are > > used. The concise MARC info online is kept up-to-date and it does > > contain examples to help clarify proper usage. For 852 surf to > > URL <http://www.loc.gov/marc/bibliographic/ecbdhold.html#mrcb852> > > > From the prescribed definition and usage examples given, you will > > note that [blah, blah, blah, snip] > > > Mapping for 852a, 852b, and 852f should not be treated > > arbitrarily. > >My understanding is that the 852 field is all for "local" data, and is >mainly for use within an organization. Is that true? It seems that our >library staff has manually added all the 852 data since we automated, >and this is where the majority of irregularities occurs in our MARC >records. I snipped back some of my verbiage to make the more important parts a little more identifiable. Yes, your understanding is correct, Larry, in that 852 is "mainly" for use within an organization. However (you knew this was coming, didn't you? ;-) ) ... Part of the whole purpose of creating MARC records was the sharing of cataloguing data. LC proves this daily by giving us all free access to its records (well, one has to have the Internet, etc., etc., but that's not their fault). Part of what we're supposed to be doing, as cataloguers, is obey the conventions (AACR2R, ISBD, etc.) and the standards for use of the MARC21 system (this is why we are given examples, and for those lucky enough to work in libraries that can afford such, access to the Library of Congress Rule Interpretations, LCRIs). If sharing is going to be possible, we do have to look at how things are set up. Yes, it was arbitrary (small groups of people working mainly at LC), but it is thorough. It isn't really a good idea to start switching things around. I remember Athena very well. Especially the arguments I had with my so-called assistant over the useless entry of data like source of acquisition date, fund, price, all of which can be entered in other MARC fields properly kept out of patron's prying eyes anyway (no, I know that data isn't useless, but it can be very frustrating to try explaining to a patron why you're charging them $25 to replace a book they lost when your own catalogue says it only cost $5 [way back in 1979, of course] and I would still rather spend cataloguing time on Authority Records or at least on augmenting the collection with good 520s, genre labels and keywords to improve search results). While I admire the ingenuity of the computer-savvy in creating these wonderful systems -- and Athena is a very neat system that I quite like -- the problems it runs into are largely of its creators own making in deliberating deciding they know better than the sages of LC. >The reason I chose the arbitrary mappings I did was because our current >MARC records have no data in those subfields, so there would be no >conflict in importation into Koha. [snip] When I was in grad school for history, my advisor constantly warned us students of the dangers of present-ism: 'If it's this way now, that's how it will always be, how it always was.' So, while I completely sympathise, Larry, LC-NLC have determined the usage of the field and subfields therein and it really isn't a good idea not to follow form. Who knows what developments in the future will bring? It makes it easier if we're all playing the game with the same rule book, even just for the present, let alone the future. The idea that all cataloguing is isolated from affecting others really belongs to the pre-MARC/online era. If we all follow the rules, we can all help each other out now and in the future. In the alternate mapping I suggested (and keep in mind, that's only my off-the-cuff attempt; it has no particular authority), I assumed you wanted to use the one field 852, so I just chose subfields that would allow you to do what you wanted within that one field. (BTW if the tab thing you were writing about to Derek would allow keeping the data in allowed subfields only, that would be preferable to what I suggested viz. a $d or $w.) >The manual for our current software (Sagebrush's Athena) suggests this >mapping: > > 852 6 --> Format (eg, book, paperback) > 852 7 --> Aquisition fund > 852 8 --> Aquisition date [well, you know that ain't allowed!! in fact, if you followed convention and inputted the date in this field, e.g. as 20030724, depending on what system you migrated to later, you could have real fun with the computer trying to find something to link to] > 852 9 --> Aquisition price When I was first confronted with this, I was mighty perturbed. I understand that Athena's programmers wanted to collect the data in one field: all they needed to do though was use multiple 852 $x fields! There is no reason at all for their creativity!! Following the rules would actually simplify matters. Personally, I would have preferred the data to be placed in a good old 037 tag. To my mind, its subfields provide for all of the above, plus it can be entered at the time one creates a temporary minimal record (to indicate to patrons searching that an item is on-order for example) without the need to muck about with the 852 or other call number field until the work is received in cataloguing. The map for the 037, is simple $a Stock number - possibly useful for re-ordering/replacement $b Source of stock number/acquisition ** $c Terms of availability = (in almost all cases) price ** $f Form of issue - easily adaptable to be an institution's needs with a ltd. institution-specific set of terms or more ones more generally recognised $n Note - where you could easily enter acquisition fund (usually coded in most institutions anyway), order date and received-in date ex. 037 _ _ $bBook Barn $c$22.50 $c$5.00 (sale price) $fTrade pbk. $nGenBkFund; ordered 20021209; received 20030108. >Given the discrepancy between this usage and that laid out in the >Library of Congress website, I'm wondering just how standardized actual >MARC implementaions are across all libraries? Not very standardised, as you rightly hint. Or at least, not so much in the details. Core fields like the 008, 100, 245, 250, 260, 300 tend to be pretty good. But that doesn't mean we should stop trying. If it makes you feel any the better, I keep running across records in the NLC database where contributing cataloguers still aren't even following ISBD description rules for newer records (ca. 1985) and the ISBD rules, IIRC, are older than me! As a cautionary tale, let me warn you about what happened to one school division in Winnipeg. For years that division (and the one I reside and have worked in) used TKM Microcat, a decent system for when it was first created. They were told not to bother coding the 008 -- a core required field -- because that system didn't really use it (can't sort results by date, e.g. because of this). That minor reduction in labour over the years came as little comfort to the division's cheque book a few years back when all the schools had to send ALL their records for RECON because the new system they migrated to was MARC-compliant and viewed the records it was fed as the garbage they were! I kinda think LC should start gathering up a page of horror stories like this to remind folks why it is important to follow those nagging standards, even when it doesn't seem to have any purpose at the time. ;-) In any case, LC sets the structure (and it isn't completely autocratic BTW: someone at your level of authority in a library can make suggestions; my former supervisor did) and if you think it's difficult now, think what might happen if they designate something your system was using for a different purpose and many others go along with the change. Either 'welcome back to the age of splendid isolation' or See above for 'The moral of the story is ...' >I went ahead and made some small changes, like changing "fic", "Fic", >"FiC", all to "FIC" and limiting further entries into the Athena >database to "FIC" for fictional books. That amounted to a criminal >offence (almost), according to the staff. :) I would've brought you a thank-you card and cake! ;-) >From a management point of view, I think it will be easier to just get >the data correctly imported into Koha's database tables and do the >correction and standardization in that database. Then limiting manual >biblio entries to only authorized standard values and/or formats can be >hidden within the general chaos of implementing new software. I agree. Plus making the patrons feel more at ease and part of the positive change, and this is of no inconsiderable value! Anyway, I hope some of what I've said this time makes sense, too, and that it may be useful to you and others. Cheers from Winnipeg, Steven F. Baljkas library tech at large Koha neophyte

1 0

Re:[Koha] data import question
by baljkas＠mb.sympatico.ca 24 Jul '03

24 Jul '03

Tuesday, July 22, 2003 18:20 CDT Hi, Derek, You were dead-on right in your interpreting >I believe (correct me if I'm wrong) that I want the 016.9733 to end up >in biblioitems.classification and the C475m to end up in >biblioitems.subclass. Whether the gods of LC should ever have caused so much trouble in splitting up the constituent parts of a call number, the numbers map as you suggested from 852h (the classification number, i.e. the sequence of alphanumerics for all items on a given subject/topic) and 852i, the completion of the call number (the item number, i.e. the sequence of alphanumerics yielding a unique address/identifier for that particular object). Some libraries seem to ignore the formal definition of the 852h and enter the WHOLE call number in that field (classification part and item specific designator); this certainly makes things easier, although it is not strictly speaking correct. You could make a similar pitch to use the 852c that way, although again, not strictly speaking correct. Just a quick addendum re: Larry Stamm's response -- at least, I think it was Larry's part infra, but I wasn't quite clear who was writing, so my apologies to Larry if this is a misattribution -- viz. what is arbitrary in the '852'. Of course, all of the structure of tags and subfields is arbitrary (in the sense of having no real reason for having been designated as they are), but the mapping of the 852 is a little more defined now. Remember to check LC's MARC documentation to see what fields and subfields within fields are defined and how they are used. The concise MARC info online is kept up-to-date and it does contain examples to help clarify proper usage. For 852 surf to URL <http://www.loc.gov/marc/bibliographic/ecbdhold.html#mrcb852> >> > The mapping that I am trying at the moment is: >> > >> > items.itemnumber -> 852 f (arbitrary mapping - no data in this >> > subfield in the original MARC record of our old system ) >> > >> > items.multivolumepart -> 852 m >> > items.barcode -> 852 p >> > items.dateaccessioned -> 852 8 >> > items.homebranch -> 852 a (arbitrary mapping) >> > items.price -> 852 9 >> > items.itemnotes -> 852 z >> > items.holdingbranch -> 852 b (arbitrary mapping) >> > >> > Your mappings might have to be slightly different depending on >> > where your current MARC records are storing data. Since many of >> > our library's records were entered by hand, I am having to "fix and >> > reconstitute" the MARC database to standardize the entries. This >> > is not proving to be an easy job to catch every error. >> > >> > The rest of the columns in the items tables are left unmapped for >> > now. # From the prescribed definition and usage examples given, you will note that 852 $8 is designated for Link and Sequence Number 852 $9 is not defined [numbers tend to be avoided though] 852 $a is prescribed: it must be a valid Organization Code 852 $b is prescribed: as Sublocation or Collection 852 $f is prescribed: Coded Location Qualifier, to distinguish subparts or specific issues of an items that are located apart from the main holdings of the same item Mapping for 852a, 852b, and 852f should not be treated arbitrarily. Your 852b will doubtless be correct. For the 852a, you may have a valid location code assigned to your library: check the MARC list for organizations or ask your librarian for the Library Symbol, WHO code, etc. or whatever is normal for your library. Your usage of 852m and 852p seems fine (I've certainly seen many examples of them used as you propose). For the rest, I'd suggest an alternate mapping: items.price --> 852 $x Non-public note [LC ex. gives accession no.] items.itemnumber --> 852 $w [unused; unlikely to be used in future] items.dateaccessioned --> 852 $d [unused; unlikely to be used in future: if possible, you could use a second 852x, since LC allows this as a repeatable subfield] If you employ $w and $d, you'd avoid potential overwrite problems in the future when importing records or making global changes. >> > Your mappings might have to be slightly different depending on >> > where your current MARC records are storing data. Since many of >> > our library's records were entered by hand, I am having to "fix and >> > reconstitute" the MARC database to standardize the entries. This >> > is not proving to be an easy job to catch every error. You might be able to use a tool like MARCEdit (available off the LC MARC tools page) to do simple global edits. You would need to copy data from fields you know it is currently stored in, transfer it to a temporary dummy field (a 9xx) where you can set up the data as you need. Once you have all the data in standardised places, you could use a global change delete to remove the 852's that are there and then reconstruct them as you need them from the correct locations in the dummy fields you set up. Just a thought anyway. Kudos to Larry for an incredibly well-thought-out and complete explanation. Good luck with your presentation, Derek. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB CANADA original discussion follows below ---------------------------------- Derek Dresser <Derek.Dresser(a)gouldacademy.org> wrote: >Quoting Derek Dresser <Derek.Dresser(a)gouldacademy.org>: > >> Quoting Larry Stamm <larry(a)larrystamm.com>: >> >> > Derek Dresser <Derek.Dresser(a)gouldacademy.org> writes: >> > >> > >> > > Is there an already defined option to extract the "item" data >> > > from the MARC 852 field (I believe from some responses that I >> > > have received that this is a fairly standard location for the >> > > "item" data). Any help or additional information would be >> > > appreciated. Perhaps there is a way for me to rewrite my MARC >> > > data so that that information will be read properly? >> > >> > Hi Derek, >> > >> > No, you have to define the mappings from the marc fields to the >> > items table yourself. This is done in from the Koha intranet >> > interface, going to the Parameters link, and then to the "Links >> > Koha-MARC DB" link, and then to the items tab from the drop-down >> > menu. Then you start mapping the koha items table column names to >> > MARC subfields. >> > >> > Note that _all_ of these mappings have to be in the subfields of >> > the same MARC field, so that if you are using the 852 field (as our >> > library is) then all the needed items table columns will need to be >> > mapped to 852 subfields. >> > >> > The mapping that I am trying at the moment is: >> > >> > items.itemnumber -> 852 f (arbitrary mapping - no data in this >> > subfield in the original MARC record of our old system ) >> > >> > items.multivolumepart -> 852 m >> > items.barcode -> 852 p >> > items.dateaccessioned -> 852 8 >> > items.homebranch -> 852 a (arbitrary mapping) >> > items.price -> 852 9 >> > items.itemnotes -> 852 z >> > items.holdingbranch -> 852 b (arbitrary mapping) >> > >> > Your mappings might have to be slightly different depending on >> > where your current MARC records are storing data. Since many of >> > our library's records were entered by hand, I am having to "fix and >> > reconstitute" the MARC database to standardize the entries. This >> > is not proving to be an easy job to catch every error. >> > >> > The rest of the columns in the items tables are left unmapped for >> > now. >> > >> > In addition, you have to go to the "MARC tag structure" link under >> > Parameters and change the tab value of all the subfields used in >> > the items table to "items(10)", except for the tab value of >> > items.itemnumber which should be set to "-1(ignore)" since this >> > value will be autoincremented by the bulkmarcimport script and >> > should not read any values that might inadvertently be in your MARC >> > records that you are trying to import. >> > >> > Then go back to the main Parameters page, and click the "MARC >> > Check" link. This will check all your MARC-Koha mappings to see if >> > they are valid. If there are errors, it will point them out and you >> > need to fix them before trying to use the bulkmarcimport script. >> > >> > Once you get an error free message from "MARC-Check", then you >> > should be good to use bulkmarcimport. Remember to use the "-d" >> > option to delete the previous entries. >> > >> > Once you get the biblio data into the items tables, the circulation >> > data from your old system can be extracted and added to the table >> > if you want. You will probably have to write your own script to >> > automate this, since each library system seems to store its >> > circulation data in a lightly different fashion. >> > >> > I find the bulkmarcimport script to be interminably slow, entering >> > only about 6000 items per hour on our 950 MHz CPU server running >> > Mandrake 9.0. It is not much slower on my 266 MHZ home machine >> > that I am using as a test machine. Because I have to enter all >> > 15,000 items from our collection to really test for errors in my >> > MARC "munging", it means another 2 1/2 hr wait to load up all the >> > items again after fixing a mistake before testing. I might get >> > frustrated enough to try my hand at writing a faster upload >> > script... >> > >> >> Larry, >> this is ENORMOUSLY helpful. Thank you. I am getting closer. I >> still have one error when I run MARC Check. >> >> >> ALL items fields MUST : >> >> be mapped to the same tag, >> and they must all be in the 10 (items) tab >> >> here is my mapping. >> >> items.itemnumber -> 852f (arbitrary) >> items.barcode -> 852p >> items.homebranch -> 852a (arbitrary) >> items.itemnotes -> 852z (arbitrary) >> items.holdingbranch -> 852b (arbitrary) >> >> I did set all the items fields to "item(10)" except for >> items.itemnumber which is set to -1 "ignore" >> >> The only actual fields that seem to be used in my data are >> 852h - call number >> 852p - bar code >> >> anything obvious that I'm missing? Also, where is the call number >> supposed to end up? by call number, I think I mean dewey number and >> local call number. It looks like this in my data _h016.9733 C475m >> >> Thanks again. With your help, I'm getting closer. > >Hi again, > >Is it true that the 016.9733 part of the 852h field (example above) >supposed to end up in biblioitems.classification and the C475m part > supposed to end up in biblioitems.subclass? > >When mapping the MARC subfield structure, is the "tab" parameter used >to extract multiple values from the same subfield? For example from >above would the 016.9733 be subfield 852h tab0? and C475m be subfield >852h tab1? or am I misinterpreting the "tab" parameter? > >I imported a small subset of my data using the mapping above (even >though MARC Check still reports the one error shown above) I now get >data in my items table in the database. The problem I am having now is >that the biblioitems.classification field is NULL for all my records >even though it is mapped to 852h.

2 1

Extension File for Marc Format
by rahayu rms 24 Jul '03

24 Jul '03

Hi, What the extension file to import Marc Record? Either record.dat or record.bib or...... _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp

1 0

RE: [Koha] data import question
by Bigwood, David 23 Jul '03

23 Jul '03

Steven mentions the MARC list for organizations. That can be found at: http://www.loc.gov/marc/organizations/orgshome.html#requests If you do not have a code it is easy to request one, just fill in the on-line form. Aside from being used in 852 a it is can also be used in the 003 and 040 fields. Sincerely, David Bigwood bigwood(a)lpi.usra.edu Lunar & Planetary Institute Cataloging News http://www.catalogablog.blogspot.com -----Original Message----- From: baljkas(a)mb.sympatico.ca [mailto:baljkas@mb.sympatico.ca] Sent: Tuesday, July 22, 2003 6:21 PM To: Derek.Dresser(a)gouldacademy.org; koha Cc: baljkas(a)mb.sympatico.ca Subject: Re:[Koha] data import question Your 852b will doubtless be correct. For the 852a, you may have a valid location code assigned to your library: check the MARC list for organizations or ask your librarian for the Library Symbol, WHO code, etc. or whatever is normal for your library. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB CANADA

1 0

Re: [Koha] data import question
by Derek Dresser 22 Jul '03

22 Jul '03

Quoting baljkas(a)mb.sympatico.ca: > Monday, July 21, 2003 17:59 CDT > > Hey, Derek, > > From the output script you supplied, you are definitely dealing with USMARC > (learn to start calling it MARC21, though since you will be seeing more > "harmonized" records in the years to come). > > >The issue I am still having is that it is creating biblios and > > biblioitems in the database, but no "items" > > Wasn't this question addressed about a week ago? It was brought up, but I haven't found a solution yet. Did I miss something? > > > This seems to be a problem of correctly mapping the fields in the MARC > >record to koha's database. specifically, the item information seems to > > be in MARC field 852. > > MARC field 852 is holdings information, so yes, the call number for a book, > what library or branch thereof it is at, its call number/s, its barcode/s, > etc may be in the 852's appropriate subfields. > > > I haven't yet been able to map things correctly though. I have a few > > questions. When installing, I am selecting MARC21 parameters instead > > of UNIMARC. Is this correct? What's the difference? > > You don't really want to know what the difference is. ;-) Seriously though, > if you have a 245 field in MARC, you are dealing with USMARC, UKMARC, > CANMARC or MARC21. 245 is the tag for Title and Statement of > Responsibility, and is a required core field. In UNIMARC, you'd be looking > at a 200 for just the Title. So you have chosen the correct MARC flavour, > but your mapping may still be off. > > Hopefully, someone in the technical know-how branch will get back to you on > mapping and getting the MARC data to come through at the Item level. > > >Is there an already defined option to extract the "item" data from the > > MARC 852 field (I believe from some responses that I have received >that > this is a fairly standard location for the "item" data). Any > >help or additional information would be appreciated. Perhaps there is > >a way for me to rewrite my MARC data so that that information will be > >read properly? > > Be careful in re-writing MARC data, because it is a data compression > formula and you don't want to do anything that will compromise the > structure of a record. There may be a way to do what you want, but I would > check out the info on MARC records structure at > > URL <http://www.log.gov/marc/umb/um11to12.html> > first. > > For info on the 852 field (best to understand it completely before trying > to remap it) see > > URL <http://www.loc.gov/marc/bibliographic/ecbdhold.html#mrcb852> > > and for other mappings that might provide useful examples see > > URL <http://www.loc.gov/marc/marcdocz.html> > > If you have any questions about library terminology re the MARC stuff, I'd > be glad to try and help. Just give me a shout. > > Post this to the Koha listserv if you find it helpful. > Good luck with your presentation! > Steven, Thanks much. This is very helpful for me. I'm going to copy it to the list in case there are other budding library scientists out there. -Derek > Cheers, > Steven F. Baljkas > library tech at large > Koha neophyte > Winnipeg, MB CANADA > > > > -- Derek Dresser http://network.gouldacademy.org/ Gould Academy Bethel, ME 04217 (207)824-7700 "Nothing endures but change" --Heraclitus ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Re: [Koha] MARC RECORD PROBLEM on V2.0.0
by Stephen Hedges 21 Jul '03

21 Jul '03

These records don't look like they are in iso2709 format, which is required by the bulkmarcimport.pl script (and any other script that uses the perl MARC::Record module). Try running bulkmarcimport.pl -t to test your records. Stephen Hedges > Hi..... > > I have installed koha Koha - V2.0.0pre2. on > windows and successfully run.But > I have problem to import 5000 marc record into > koha .I would like to test > koha > using our data. > Anybody know how to transfer data using marc > record.These are sample data.Is > it in the correct format?.I need some help.I hope > somebody can explain how > to do it & how the format? > > > Rec stat: n > Entered: 20021020 Replaced: 20021020 > Type: a ELvl: 1 Srce: a Audn: > Ctrl: Lang: eng > BLvl: m Form: Conf: 0 Biog: > MRec: Ctry: xxk > Cont: GPub: Fict: 0 > Indx: 0 > Desc: a Ills: Fest: 0 DtSt: e > Dates: 2002, > ÿ040 ßc KUI > ÿ020 0471126500 > ÿ050 HG4751 ßb .C36 2002 > ÿ090 HG4751 ßb .C36 2002 > ÿ049 KUIM > ÿ100 1 Camp, Justin J. > ÿ245 10 Venture capital due diligence ßb a guide > to making smart investment > choices and increasing your portfolio returns ßc > Justin J. Camp > ÿ260 New York : ßb John wiley : ßc 2002 > ÿ300 xi, 258p. : ßc 24cm > ÿ504 Includes bibliographical references and > index > ÿ650 0 Venture capital > Ü650 0 Rate of return > Ü999 000010424 > > > OCLC: NEW Rec stat: n > Entered: 20021020 Replaced: 20021020 > Type: a ELvl: 1 Srce: a Audn: > Ctrl: Lang: eng > BLvl: m Form: Conf: 0 Biog: > MRec: Ctry: xxk > Cont: GPub: Fict: 0 > Indx: 0 > Desc: a Ills: Fest: 0 DtSt: e > Dates: 2002, > ÿ040 ßc KUI > ÿ020 0471126500 > ÿ050 HG4751 ßb .C36 2002 > ÿ090 HG4751 ßb .C36 2002 > ÿ049 KUIM > ÿ100 1 Camp, Justin J. > ÿ245 10 Venture capital due diligence ßb a guide > to making smart investment > choices and increasing your portfolio returns ßc > Justin J. Camp > ÿ260 New York : ßb John wiley : ßc 2002 > ÿ300 xi, 258p. : ßc 24cm > ÿ504 Includes bibliographical references and > index > ÿ650 0 Venture capital > Ü650 0 Rate of return > Ü999 000010424 > > > OCLC: NEW Rec stat: n > Entered: 20021020 Replaced: 20021020 > Type: a ELvl: 1 Srce: a Audn: > Ctrl: Lang: eng > BLvl: m Form: Conf: 0 Biog: > MRec: Ctry: xxk > Cont: GPub: Fict: 0 > Indx: 0 > Desc: a Ills: Fest: 0 DtSt: e > Dates: 2002, > ÿ040 ßc KUI > ÿ020 0471126500 > ÿ050 HG4751 ßb .C36 2002 > ÿ090 HG4751 ßb .C36 2002 > ÿ049 KUIM > ÿ100 1 Camp, Justin J. > ÿ245 10 Venture capital due diligence ßb a guide > to making smart investment > choices and increasing your portfolio returns ßc > Justin J. Camp > ÿ260 New York : ßb John wiley : ßc 2002 > ÿ300 xi, 258p. : ßc 24cm > ÿ504 Includes bibliographical references and > index > ÿ650 0 Venture capital > Ü650 0 Rate of return > Ü999 000010424 > > > OCLC: NEW Rec stat: n > Entered: 20021020 Replaced: 20021020 > Type: a ELvl: 1 Srce: a Audn: > Ctrl: Lang: eng > BLvl: m Form: Conf: 0 Biog: > MRec: Ctry: xxk > Cont: GPub: Fict: 0 > Indx: 0 > Desc: a Ills: Fest: 0 DtSt: e > Dates: 2002, > ÿ040 ßc KUI > ÿ020 0471126500 > ÿ050 HG4751 ßb .C36 2002 > ÿ090 HG4751 ßb .C36 2002 > ÿ049 KUIM > ÿ100 1 Camp, Justin J. > ÿ245 10 Venture capital due diligence ßb a guide > to making smart investment > choices and increasing your portfolio returns ßc > Justin J. Camp > ÿ260 New York : ßb John wiley : ßc 2002 > ÿ300 xi, 258p. : ßc 24cm > ÿ504 Includes bibliographical references and > index > ÿ650 0 Venture capital > Ü650 0 Rate of return > Ü999 000010424 > > > OCLC: NEW Rec stat: n > Entered: 20021020 Replaced: 20021020 > Type: a ELvl: 1 Srce: a Audn: > Ctrl: Lang: eng > BLvl: m Form: Conf: 0 Biog: > MRec: Ctry: xxk > Cont: GPub: Fict: 0 > Indx: 0 > Desc: a Ills: Fest: 0 DtSt: e > Dates: 2002, > ÿ040 ßc KUI > ÿ020 0471126500 > ÿ050 HG4751 ßb .C36 2002 > ÿ090 HG4751 ßb .C36 2002 > ÿ049 KUIM > ÿ100 1 Camp, Justin J. > ÿ245 10 Venture capital due diligence ßb a guide > to making smart investment > choices and increasing your portfolio returns ßc > Justin J. Camp > ÿ260 New York : ßb John wiley : ßc 2002 > ÿ300 xi, 258p. : ßc 24cm > ÿ504 Includes bibliographical references and > index > ÿ650 0 Venture capital > Ü650 0 Rate of return > Ü999 000010424 > > __________________________________________________ > _______________ > Download ringtones, logos and picture messages > from MSN Malaysia > http://www.msn.com.my/mobile/ringtones/default.asp > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

z3950 problem in 2.0.0pre2
by Krzysztof Michalak 21 Jul '03

21 Jul '03

Hi, I'm trying to get koha 2.0.0pre2 running. I got through the basic installation and even figured out a few of the bugs along the way (missing Event.pm, some hardcoded paths, etc). Now I run the processz3950queue deamon and try to add an acquisition using a z3950 ISBN search. However, I get a "Still ?? requests to go" message. If I inspect the processz3950queue log file I see first a number of lines resembling : Malformed UTF-8 character (1 byte, need 2, after start byte 0xd0) at /usr/local/koha/C4/Biblio.pm line 2265. Malformed UTF-8 character (1 byte, need 2, after start byte 0xd8) at /usr/local/koha/C4/Biblio.pm line 2266. Then I get the following : starting loop Library ==> at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 156. Processing isbn="0201648652" at Library (1 forks) Library ERROR: Can't call method "option" on an undefined value at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 157. done. To me it seems like the connection to the database failed (the option method is being called on $conn). In fact I did a bit of debugging and it seems (I could be wrong) that the servername, database, user, etc variables are never set correctly. In the parameters, the z3950.loc.gov server is listed with the default values after installation. (checked =1) Where did I go wrong? Thanks, Chris

4 6