| Summary: | bulkmarcimport.pl: Should we move the old 001 to 035 ? | ||
|---|---|---|---|
| Product: | Koha | Reporter: | David Cook <dcook> |
| Component: | MARC Authority data support | Assignee: | Galen Charlton <gmcharlt> |
| Status: | RESOLVED WISHLIST | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | emjhet, flyingendpaper, frank.hansen, glasklas, m.de.rooy |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12734 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8579 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | 18014 | ||
| Bug Blocks: | |||
|
Description
David Cook
2014-08-06 03:05:00 UTC
Replacing an Authority: 1) Staged MARC Managament The 001 of the replacement record will be used, even if it's not the "authid". 2) bulkmarcimport.pl I haven't tested this... but it looks like the match is done on 001 so it'll be whatever the 001 one was in the incoming and the existing record (or the incoming 001 and the YAML mapping for the existing record). When bulk importing an authority record, we should probably be moving the 001 into another field such as the 035$a, since the 001 should be storing Koha's local authid (according to how we handle the 001 for authorities in Koha, not necessarily according to the MARC specification). bulkmarcimport.pl let's us do that with -keepids=035a, but it's tempting to enforce it for all imports...because otherwise we could lose data that we need later for matching. Of course, moving the 001 to the 035$a doesn't follow MARC spec 100%. As the 035$a should be "(OldMarcOrgCode)OldControlNumber", which wouldn't be useful for matching. We'd want to just use "OldControlNumber", otherwise it wouldn't match anyway. I have also encountered this issue. I'm tempted to have the opinion that it should be enforced that "(003)001" is moved to 035$a (if 001 is not already the internal koha id) on import since I interpret this behavior as being part of the MARC standard. At least it should be an option. Was thinking about adding this in the form of a custom script (-custom), but really think it should be added into the default logic. (In reply to David Gustafsson from comment #3) > I have also encountered this issue. I'm tempted to have the opinion that it > should be enforced that "(003)001" is moved to 035$a (if 001 is not already > the internal koha id) on import since I interpret this behavior as being > part of the MARC standard. At least it should be an option. Was thinking > about adding this in the form of a custom script (-custom), but really think > it should be added into the default logic. Report 18014 now deals consistenly with field 001. The suggested change for bulkmarcimport.pl could be done on this report ? Seems like Koha keeps the old 001 though, (instead of replacing it with the local koha id). So if that it the also copying it to 035a is a bit confusing. So not really sure how to tackle this one. (In reply to David Gustafsson from comment #5) > Seems like Koha keeps the old 001 though, (instead of replacing it with the > local koha id). So if that it the also copying it to 035a is a bit > confusing. So not really sure how to tackle this one. Please have a look at bug 18014. Now Koha always stores the local id into 001. Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm quite new to Koha and marc, so I might be completely wrong, but I don't understand why the handling of 001 and 035a should be handled differently between the two. When importing a bibliographic record into Koha I would expect 001 to be replaced with the Koha local id, and the previous 001 moved to 035a. (In reply to David Gustafsson from comment #7) > Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm > quite new to Koha and marc, so I might be completely wrong, but I don't > understand why the handling of 001 and 035a should be handled differently > between the two. When importing a bibliographic record into Koha I would > expect 001 to be replaced with the Koha local id, and the previous 001 moved > to 035a. Yeah, we were talking authorities. On several reports there was indeed discussion about the biblionumber in 001. Until now no results yet. (In reply to David Gustafsson from comment #7) > Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm > quite new to Koha and marc, so I might be completely wrong, but I don't > understand why the handling of 001 and 035a should be handled differently > between the two. When importing a bibliographic record into Koha I would > expect 001 to be replaced with the Koha local id, and the previous 001 moved > to 035a. I know this thread was originally about authorities, but it went nowhere. And regardless of the type of record, we really do need a way to move the 001 to the 035, as mentioned in other bugs. Please do not disregard this problem. Can this be made into a Cronjob or something? (In reply to emjhet from comment #9) > (In reply to David Gustafsson from comment #7) > > Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm > > quite new to Koha and marc, so I might be completely wrong, but I don't > > understand why the handling of 001 and 035a should be handled differently > > between the two. When importing a bibliographic record into Koha I would > > expect 001 to be replaced with the Koha local id, and the previous 001 moved > > to 035a. > > I know this thread was originally about authorities, but it went nowhere. > And regardless of the type of record, we really do need a way to move the > 001 to the 035, as mentioned in other bugs. Please do not disregard this > problem. Can this be made into a Cronjob or something? A cronjob wouldn't make sense for this. It'll need to be a mechanism added to import functionality. Could there be some way to choose this or not (e.g., syspref)? We are an OCLC library, and retain the OCLC record number in the 001 when importing authorities as our primary key; we match and replace authority records on the 010 field (Library of Congress Control Number). We (and perhaps other OCLC users) would definitely not want the OCLC number data moved out of the 001 field and into the 035 upon import. (The 001 also contains the OCLC record number in our bibs.) Could the desired moving of 001 data to 035 be accomplished with the new MARC modification templates capabilities upon record import? (So then maybe this enhancement isn't needed?) We are not an OCLC library, but our workflow is tied to 001 being the ID from our union catlalog, so in a similar situation. At the moment it seems not easy to match well on 035 or at least more error prone with a lot of different prefixes? (In reply to Katrin Fischer from comment #12) > We are not an OCLC library, but our workflow is tied to 001 being the ID > from our union catlalog, so in a similar situation. At the moment it seems > not easy to match well on 035 or at least more error prone with a lot of > different prefixes? In a MARC21 catalog, the 035 would contain a lot of different prefixes, c.f. examples at https://www.loc.gov/marc/bibliographic/bd035.html, e.g. these: 035 ##$a(CaOTULAS)41063988 035 ##$a(WaOLN)wln7986864 035 ##$a(DNLM)S30545600(s) The standard formatting of the required prefixes as stored in the 035 are formatted very differently from how the number would be formatted in the 001, so moving the data from an 001 into a correctly formatted 035 would be rather complicated. It's not something I'd want as default behavior in my Koha catalog at all, for either my authority or my bibliographic records. For authority records, we would always want to match on the 010 Library of Congress Control number, since that's stable no matter where the authority record comes from. Closing this one due to age, but happy for someone else to take it over |