Importing records preserving the system number
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Stefano, We have thought about this for some of our customer requirements but have (quickly) concluded that using the biblionumber (and biblioitemnumber) in koha is not the way to achieve this linking. If you have a number that has significance to you and your data then put that into the 001 control number field (Marc21). You can link to that from 77x just as easily as with biblionumber. If you try to use biblionumber for these links and you reload your data then all the numbers will be wrong. The search for contents of the 001 field (say 12345) would be: Control-number:12345 I hope this helps. Ian On 26/01/2011 10:11, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Ian Bays Director of Projects PTFS Europe.com mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.bays@ptfs-europe.com
We have found that using the Control-number:##### to be extremely slow and undependable. In our case, at least, this is definitely not a workable "solution" and is barely a solution at all. On 1:59 PM, Ian Bays wrote:
Hi Stefano, We have thought about this for some of our customer requirements but have (quickly) concluded that using the biblionumber (and biblioitemnumber) in koha is not the way to achieve this linking.
If you have a number that has significance to you and your data then put that into the 001 control number field (Marc21). You can link to that from 77x just as easily as with biblionumber.
If you try to use biblionumber for these links and you reload your data then all the numbers will be wrong.
The search for contents of the 001 field (say 12345) would be:
Control-number:12345
I hope this helps.
Ian On 26/01/2011 10:11, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
We have used the control number as our stable number. But as I understand it the 77X link is done with a title search. This works well for some things with unique titles, and is nearly useless for others. A proper link based on the search for the control number would bring about an exact match, in theory. The other problem with control numbers: They don't auto generate. Any numbers for new items that we create must be unique. So far the date, time and cataloguer's initials is the best option I can come up with (eg 201101311346EB for me, now) But it's easy to miss type something and it makes for a very long number. . . Elaine On Thu, Jan 27, 2011 at 2:21 PM, Linda Culberson <lculber@mdah.state.ms.us> wrote:
We have found that using the Control-number:##### to be extremely slow and undependable. In our case, at least, this is definitely not a workable "solution" and is barely a solution at all.
On 1:59 PM, Ian Bays wrote:
Hi Stefano, We have thought about this for some of our customer requirements but have (quickly) concluded that using the biblionumber (and biblioitemnumber) in koha is not the way to achieve this linking.
If you have a number that has significance to you and your data then put that into the 001 control number field (Marc21). You can link to that from 77x just as easily as with biblionumber.
If you try to use biblionumber for these links and you reload your data then all the numbers will be wrong.
The search for contents of the 001 field (say 12345) would be:
Control-number:12345
I hope this helps.
Ian On 26/01/2011 10:11, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Elaine Bradtke Data Wrangler VWML English Folk Dance and Song Society | http://www.efdss.org Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY Tel +44 (0) 20 7485 2206 ext 36 -------------------------------------------------------------------------- Registered Company No. 297142 Charity Registered in England and Wales No. 305999 --------------------------------------------------------------------------- "Writing about music is like dancing about architecture" --Elvis Costello (Musician magazine No. 60 (October 1983), p. 52)
Hi Elaine, The framework can be adjusted to use (eg) Control-number as the link to "Other Item Identifier": Home › Administration › MARC Frameworks › BKF Framework Structure › Tag 775 Subfield Structure › Edit subfields constraints (subfield o) Advanced constraints, Link. I'm not sure of the reason for the "Warning: This value should not change after data has been added to your catalog". At one point I think the link only worked from the staff interface in the MARC view (for the fields we were using) but there is a need to be able to link between these items in the OPAC. Hopefully some of the analytic work will help this. We also have customers who would like an automatically-allocated, increasing, unique number for such as control number. It would be interesting to see if others have a need (or indeed a solution) to these. All the best. Ian On 31/01/2011 13:49, Elaine Bradtke wrote:
We have used the control number as our stable number. But as I understand it the 77X link is done with a title search. This works well for some things with unique titles, and is nearly useless for others. A proper link based on the search for the control number would bring about an exact match, in theory.
The other problem with control numbers: They don't auto generate. Any numbers for new items that we create must be unique. So far the date, time and cataloguer's initials is the best option I can come up with (eg 201101311346EB for me, now) But it's easy to miss type something and it makes for a very long number. . . Elaine
On Thu, Jan 27, 2011 at 2:21 PM, Linda Culberson <lculber@mdah.state.ms.us> wrote:
We have found that using the Control-number:##### to be extremely slow and undependable. In our case, at least, this is definitely not a workable "solution" and is barely a solution at all.
On 1:59 PM, Ian Bays wrote:
Hi Stefano, We have thought about this for some of our customer requirements but have (quickly) concluded that using the biblionumber (and biblioitemnumber) in koha is not the way to achieve this linking.
If you have a number that has significance to you and your data then put that into the 001 control number field (Marc21). You can link to that from 77x just as easily as with biblionumber.
If you try to use biblionumber for these links and you reload your data then all the numbers will be wrong.
The search for contents of the 001 field (say 12345) would be:
Control-number:12345
I hope this helps.
Ian On 26/01/2011 10:11, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Ian Bays Director of Projects PTFS Europe.com mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.bays@ptfs-europe.com
We have this problem as well and have been devoting a great deal of time and effort. We had figured out a "hack" for 3.0 that doesn't work in 3.2 It is out greatest obstacle to being able to migrate to Koha. On 1:59 PM, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
Sorry, all, I've been sick and it seems to affect my typing skills. I meant: We have this problem as well and have been devoting a great deal of time and effort. We had figured out a "hack" for 3.0 that doesn't work in 3.2 It is our greatest obstacle to being able to migrate to Koha. We have external databases and digitized objects tied to this number. For us, this is a nightmare situation. On 1/27/2011 7:33 AM, Linda Culberson wrote:
We have this problem as well and have been devoting a great deal of time and effort. We had figured out a "hack" for 3.0 that doesn't work in 3.2 It is out greatest obstacle to being able to migrate to Koha.
On 1:59 PM, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
Linda, Why does putting the data in the 001 not work? If the problem is just links, there's a way around that using some clever Apache (web server) hackery. Regards, Jared On Thu, Jan 27, 2011 at 8:52 AM, Linda Culberson <lculber@mdah.state.ms.us>wrote:
Sorry, all, I've been sick and it seems to affect my typing skills. I meant: We have this problem as well and have been devoting a great deal of time and effort. We had figured out a "hack" for 3.0 that doesn't work in 3.2 It is our greatest obstacle to being able to migrate to Koha.
We have external databases and digitized objects tied to this number. For us, this is a nightmare situation.
On 1/27/2011 7:33 AM, Linda Culberson wrote:
We have this problem as well and have been devoting a great deal of time and effort. We had figured out a "hack" for 3.0 that doesn't work in 3.2 It is out greatest obstacle to being able to migrate to Koha.
On 1:59 PM, Stefano Bargioni wrote:
This is an autoreply :-) I wonder why nobody have had this problem before. How can be preserved internal links -contained in fields like 77x- without preserving the system number? I'll try to solve it hacking the code (C4::Biblio), but in my opinion Koha needs a way to do this, an option in bulkmarcimport for instance. Bye. Stefano
On Jan 20, 2011, at 11:27 , Stefano Bargioni wrote:
I'm trying to migrate about 140,000 records. Each of them has 001 with the original value. I copied it into 999c and 999d. Importing in Koha, 999c and 999d are replaced by a new (autoincremented) bibliotemnumber. How can I force Koha to assign bibliotemnumbers using 001 or 999c/d? Thank you. SB _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Jared Camins-Esakov Freelance bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi all, I am converting some bibs and authorities from another system into koha and I have ended up with duplicate authorities on the koha database. I wonder if someone could point out where I went wrong or if koha is behaving as designed: Here are the steps I followed: 1. Loaded a file of 6,500 Marc Bib records using bulkmarcimport.pl 2. Rebuilt the Zebra index -b 3. Loaded a file of Authorities using bulkmarcimport.pl – As an example, this file contains 6 authority records for “Pullman, Philip” 4. Rebuilt the Zebra index -a 5. Ran link_bibs_to_authorities.pl 6. When I check the personal name authorities there are 6 “Pullman, Philip” entries, all linked to 0 bibs Do I have to dedup the authority file before I import it (not an easy task)? Any help would be appreciated Mike
Hi Mike, Step 3 added your duplicate authorities. So yes you will need to de-duplicate authorities before loading. Step 5 was not working at version 3.0 but we have seen it working at 3.2. I hope this helps. Ian On 27/01/2011 14:34, Mike McCormack wrote:
Hi all,
I am converting some bibs and authorities from another system into koha and I have ended up with duplicate authorities on the koha database. I wonder if someone could point out where I went wrong or if koha is behaving as designed:
Here are the steps I followed:
1.Loaded a file of 6,500 Marc Bib records using bulkmarcimport.pl
2.Rebuilt the Zebra index -b
3.Loaded a file of Authorities using bulkmarcimport.pl – As an example, this file contains 6 authority records for “Pullman, Philip”
4.Rebuilt the Zebra index -a
5.Ran link_bibs_to_authorities.pl
6.When I check the personal name authorities there are 6 “Pullman, Philip” entries, all linked to 0 bibs
Do I have to dedup the authority file before I import it (not an easy task)?
Any help would be appreciated
Mike
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Ian Bays Director of Projects PTFS Europe.com mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.bays@ptfs-europe.com
Hi, On Jan 27, 2011, at 10:04 AM, Ian Bays wrote:
Step 3 added your duplicate authorities. So yes you will need to de-duplicate authorities before loading.
To expand on this point, by the nature of an authority file, authority records need to be unique in just about any ILS's database. Specifically, there should be no more than one authority record per authorized main heading (or subdivision) and thesaurus. Regards, Galen -- Galen Charlton VP, Data Services Equinox Software, Inc. / Your Library's Guide to Open Source email: gmc@esilibrary.com direct: +1 352-215-7548 skype: gmcharlt web: http://www.esilibrary.com/
On Jan 27, 2011, at 15:34 , Mike McCormack wrote:
Hi all,
I am converting some bibs and authorities from another system into koha and I have ended up with duplicate authorities on the koha database. I wonder if someone could point out where I went wrong or if koha is behaving as designed: Here are the steps I followed:
1. Loaded a file of 6,500 Marc Bib records using bulkmarcimport.pl 2. Rebuilt the Zebra index -b 3. Loaded a file of Authorities using bulkmarcimport.pl – As an example, this file contains 6 authority records for “Pullman, Philip” 4. Rebuilt the Zebra index -a 5. Ran link_bibs_to_authorities.pl 6. When I check the personal name authorities there are 6 “Pullman, Philip” entries, all linked to 0 bibs
Do I have to dedup the authority file before I import it (not an easy task)?
I think so. SB
Any help would be appreciated
Mike
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (7)
-
Elaine Bradtke -
Galen Charlton -
Ian Bays -
Jared Camins-Esakov -
Linda Culberson -
Mike McCormack -
Stefano Bargioni