Hi, It would be great to have possibility using marc modification templates on Z39.50 search. Regards, Marjorie
*** Bug 26371 has been marked as a duplicate of this bug. ***
I'd love to see some more action on this bug because I think this would be great functionality. We get brief bib records when we order from our vendor. When cataloging in the advanced editor we overlay the brief bib with a full MARC record via Z39.50. Sometimes the incoming record has tags that we do not want in our bibs (local 9XX tags, 852, local 59x notes, etc.) We'd like a way to prevent those tags from being imported instead of having to delete them from every incoming record. We'd also like a way to add or modify fields in the incoming record such as changing an incoming 092 to an 099. These are some examples of what we would like to have automatically removed from the incoming records: Delete all 9xx tags Delete all 852 tags Delete all 59x tags Delete all 69x tags Delete subfield ‡0 from all 1xx, 6xx, 7xx and 8xx tags - Example: 600 1 0 ‡aObama, Michelle,‡d1964-‡0823994 Delete 6xx subject headings that contain a subfield ‡2fast‡0(OCoLC) - Example: 650 _ 7 ‡aAfrican American women lawyers.‡2fast‡0(OCoLC)fst00799505. Change the incoming 092 tag to an 099 tag Delete all 035 tags that do not contain (OCoLC) at the beginning Remove the  diacritic symbol from the beginning of a 264_4 tag Delete subfield ‡b of the 003 tag Add audience code to the leader
When importing a record would like the ability to delete automatically sears and bisacsh headings. At this point only a specific field number can be deleted. If we could further specify subfields or indicators that would be helpful 650 7 #2 sears and bisasch
+1 on this.
Just mentioning here, while it's not as easy for the user to setup, you can specify an XSLT file for transforming the incoming records, and this can achieve some of the desired functionality
Created attachment 165171 [details] XSL file to delete incoming 001 fields Sample file to illustrate removing fields on import from Z39.50
XSLT should do more of the desired functionality, if not all, since without bug 21860 you can't use MARC modification templates to do anything about things you only object to based on indicators, like French subjects on an English work, or the strange OCLC habit of using duplicate subject headings with the undefined second indicator 8. Unfortunately, bug 35255 means XSLT is useless for advanced editor users.
+1 on this as well from here. It's hard to imagine that almost every library doesn't have at least some basic MARC cleanup that would be great to accomplish automatically on import.
+1 here. We'd really like to be able to strip out any $w linking fields to bib numbers that may match one of our own bib numbers but be an incorrect link in our Koha. Also agree with 035 non-OCLC numbers being stripped as well as a few other fields we always have to remove.
The XSLT file would be great. It just needs some documentation. The other challenge is the user has to have access to the server (or external path) to upload or modify. So improved access would make it easier if stored locally. MARC modification templates, on the other hand, are accessible to the user and fairly straightforward to create.
(In reply to Esther Melander from comment #10) > The XSLT file would be great. It just needs some documentation. The other > challenge is the user has to have access to the server (or external path) to > upload or modify. So improved access would make it easier if stored locally. > MARC modification templates, on the other hand, are accessible to the user > and fairly straightforward to create. I second Esther's comment: modification templates are easily accessible to me and my staff, while XML is not. While templates can be applied AFTER Z39.50 import, it would be easier to apply them at import. Additionally, as others have mentioned, it would be great to be able to modify tags based on indicators - or even subfield content (to remove FAST, bisac, French, etc.)