Bug 12722 - bulkmarcimport.pl: Should we move the old 001 to 035 ?
Summary: bulkmarcimport.pl: Should we move the old 001 to 035 ?
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on: 18014
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-06 03:05 UTC by David Cook
Modified: 2020-04-30 15:50 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2014-08-06 03:05:00 UTC
Importing New Authority:

1) Staged MARC Management && Z39.50 MARC import

The 001 will be the "authid", which will be the primary key in the auth_header table.

This is regardless of whether there is a 001 in the incoming record or not.

(This is rather shocking, since you can SEE the 001 in the incoming record. But the incoming 001 will be dumped in favour of the "authid".)

2) bulkmarcimport.pl

The 001 will be the incoming 001, and NOT the "authid"...

UNLESS you use the "-keepid=FIELD" flag OR if there is no 001 on the incoming record.
Comment 1 David Cook 2014-08-06 03:09:36 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).
Comment 2 David Cook 2014-08-08 03:24:36 UTC
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.
Comment 3 David Gustafsson 2016-12-27 11:57:02 UTC
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.
Comment 4 Marcel de Rooy 2017-01-31 08:51:32 UTC
(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 ?
Comment 5 David Gustafsson 2017-01-31 10:28:00 UTC
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.
Comment 6 Marcel de Rooy 2017-01-31 13:08:23 UTC
(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.
Comment 7 David Gustafsson 2017-02-02 14:18:02 UTC
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.
Comment 8 Marcel de Rooy 2017-02-02 14:23:55 UTC
(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.
Comment 9 emjhet 2018-07-26 00:52:06 UTC
(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?
Comment 10 David Cook 2018-07-26 02:18:13 UTC
(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.
Comment 11 Heather 2020-02-19 22:41:02 UTC
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?)
Comment 12 Katrin Fischer 2020-04-29 19:50:03 UTC
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?
Comment 13 Heather 2020-04-30 15:50:33 UTC
(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.