Summary: | Fix bulkmarcimport.pl documentation | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Command-line Utilities | Assignee: | Galen Charlton <gmcharlt> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | magnus |
Version: | Main | Keywords: | Academy |
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
David Cook
2014-08-05 06:57:36 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. 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. --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. |