Bug 12719 - Fix bulkmarcimport.pl documentation
Summary: Fix bulkmarcimport.pl documentation
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords: Academy
Depends on:
Blocks:
 
Reported: 2014-08-05 06:57 UTC by David Cook
Modified: 2020-01-06 00:42 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2014-08-05 06:57:36 UTC
Currently, there are two entries for "keepids" in the perldoc for bulkmarcimport.pl.

The following code here is (mostly) correct:

 713 =item B<-k, -keepids>=<FIELD>
 714 
 715 Field store ids in I<FIELD> (usefull for authorities, where 001 contains the
 716 authid for Koha, that can contain a very valuable info for authorities coming
 717 from LOC or BNF. useless for biblios probably)

The following code here is really NOT:

 747 =item B<-keepids>
 748 
 749 Store ids in 009 (usefull for authorities, where 001 contains the authid for
 750 Koha, that can contain a very valuable info for authorities coming from LOC or
 751 BNF. useless for biblios probably)

--

It should probably be something like...

=item B<-k, -keepids>=<FIELD>

Keep the ID (i.e. control number 001) from the incoming record in I<FIELD>.

I<FIELD> should be a field/subfield pair, such as 035a, or a controlfield, such as 009.

If no I<FIELD> is provided, the 001 from the incoming record will be kept in the 001 in Koha.

(N.B. I don't know if a FIELD-less parameter would result in a bug or not...)
Comment 1 David Cook 2014-08-05 07:00:54 UTC
Of course, even with accurate documentation, there would still be some "problems":

In regards to the 035, for it to formed according to the MARC spec, it should be stored like so:

(MarcOrgCode)00000000
(DNLM)D006356Q000628 

Where MarcOrgCode should come from the 003 and 00000000 from the 001...

--

Library of Congress records should already also store their 001 in the 010... while other national bibliographic agencies can store the number in the 016$a and store the MarcOrgCode in the $2. 

If I understand that correctly, you could keep control numbers for the National Library of Medicine like so:

016 $a D006356Q000628 $2 DNLM

--

Personally, I find value in storing the 001, because you can look up that record in the system you retrieved it from.

In the case of bibliographic or authority records, you should be able to use this preserved value for matching purposes.
Comment 2 David Cook 2014-08-06 02:47:09 UTC
I think that the "update" flag might not work as expected for authorities.

If you don't specify the update flag, it'll just add authorities.

If you specify the "update" flag, it'll update records based on a matching 001, and still add authorities that don't have a matching 001.
Comment 3 Magnus Enger 2015-05-07 09:20:18 UTC
--match can be given multiple times, because of the @ here:

'match=s@'    => \$match,

but this is not mentioned in the documentation. It should also be explicitly said if multiple --match'es are ANDed or ORed.