[Bug 40119] New: Merge should not leave empty 6XX subfield $2 (MARC 21)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Bug ID: 40119 Summary: Merge should not leave empty 6XX subfield $2 (MARC 21) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs@lists.koha-community.org Reporter: januszop@gmail.com QA Contact: testopia@bugs.koha-community.org Currently, when removing 040 $f from authority record with 008/11 = 'z' (MARC 21), merge function removes the content of $2 subfield in linked 6XX fields, leaving the 6XX $2 subfield empty. This is not correct. We should not have empty subfields in a MARC record. Instead, the old content of the $2 subfield should be retained (if auth 008/11 is still = 'z'). [It is perfectly correct in MARC 21 to have authority records with 008/11 = 'z' and no 040 $f. In such a case, in the related biblio 6XX fields 2nd ind. should be = '7', and '7' implies the presence of $2 subfield, which would be filled by hand or by other means.] To reproduce: 1. Have an authority record with 008/11 = 'z' and 040 $f = 'whatever'. 2. Link the record to a bibliographic 6XX. 3. Edit the authority record, removing 040 $f. 4. Go to bibliographic record and in modal "MARC preview" from Normal view notice that 6XX $2 exists but is empty. This is an error - there should be no empty subfield in the MARC record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #1 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 183165 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183165&action=edit Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) Currently, when removing 040 $f from authority record with 008/11 = 'z' (MARC 21), merge function removes the content of $2 subfield in linked 6XX fields, leaving the 6XX $2 subfield empty. This is not correct. We should not have empty subfields in a MARC record. Instead, the old content of the $2 subfield should be retained (if auth 008/11 is still = 'z'). Test plan: ========== 1. Have an authority record with 008/11 = 'z' and 040 $f = 'whatever'. 2. Link the record to a bibliographic 6XX. 3. Edit the authority record, removing 040 $f. 4. Go to bibliographic record and in modal "MARC preview" from Normal view notice that 6XX $2 exists but is empty. This is wrong. 5. Apply the patch ; restart all. 6. Repeat p. 1.-4. Note that the content of 6XX $2 has not been removed. Sponsored-by: Ignatianum University in Cracow -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #2 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 183166 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183166&action=edit Bug 40119: Unit tests -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Change sponsored?|--- |Sponsored Patch complexity|--- |Trivial patch CC| |m.de.rooy@rijksmuseum.nl, | |nick@bywatersolutions.com Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183165|0 |1 is obsolete| | --- Comment #3 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 183175 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183175&action=edit Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) Currently, when removing 040 $f from authority record with 008/11 = 'z' (MARC 21), merge function removes the content of $2 subfield in linked 6XX fields, leaving the 6XX $2 subfield empty. This is not correct. We should not have empty subfields in a MARC record. Instead, the old content of the $2 subfield should be retained (if auth 008/11 is still = 'z'). Test plan: ========== 1. Have an authority record with 008/11 = 'z' and 040 $f = 'whatever'. 2. Link the record to a bibliographic 6XX. 3. Edit the authority record, removing 040 $f. 4. Go to bibliographic record and in modal "MARC preview" from Normal view notice that 6XX $2 exists but is empty. This is wrong. 5. Apply the patch ; restart all. 6. Repeat p. 1.-4. Note that the content of 6XX $2 has not been removed. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183166|0 |1 is obsolete| | --- Comment #4 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 183176 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183176&action=edit Bug 40119: Unit tests Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roman.dolny@jezuici.pl Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |januszop@gmail.com |ity.org | QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Janusz Kaczmarek from comment #0)
Currently, when removing 040 $f from authority record with 008/11 = 'z' (MARC 21), merge function removes the content of $2 subfield in linked 6XX fields, leaving the 6XX $2 subfield empty. This is not correct. We should not have empty subfields in a MARC record.
Instead, the old content of the $2 subfield should be retained (if auth 008/11 is still = 'z').
[It is perfectly correct in MARC 21 to have authority records with 008/11 = 'z' and no 040 $f. In such a case, in the related biblio 6XX fields 2nd ind. should be = '7', and '7' implies the presence of $2 subfield, which would be filled by hand or by other means.]
Yeah, an empty $2 is weird. But I am not completely sure about retaining the old value or removing the subfield. If we explicitly remove the 040f value from the authority (while having that old value in all linked biblio records and keeping it), wouldnt that be confusing? Do you have any MARC documentation support for leaving 040f empty to allow $2 values on the bib side (even different ones)? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off --- Comment #6 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to Marcel de Rooy from comment #5)
Yeah, an empty $2 is weird. But I am not completely sure about retaining the old value or removing the subfield.
If we explicitly remove the 040f value from the authority (while having that old value in all linked biblio records and keeping it), wouldnt that be confusing?
Do you have any MARC documentation support for leaving 040f empty to allow $2 values on the bib side (even different ones)?
Thanks, Marcel, for commenting. 1) From https://www.loc.gov/marc/authority/ad008.html, section 008/11 = 'z': "A MARC code for the conventions used to formulate the heading *may* be contained in subfield $f (Subject heading/thesaurus conventions) in field 040 (Cataloging Source)". "May" means, IMO, that it is legal to have 008/11 = 'z' and no 040 $f. 2) 008/11 = 'z' in authority implies 2nd ind. = '7' in linked 6XX fields in bibliographic record. And 2nd ind. = '7' implies the presence of $s subfield. (From https://www.loc.gov/marc/bibliographic/bd600.html: " 7 - Source specified in subfield $2 / Subject added entry conforms to a set of subject heading system/thesaurus building rules. The identifying code is given in subfield $2." 3) I agree that removing 040 $f from an authority record while leaving 008/11 = 'z' creates a fuzzy situation but IMO the best heuristics is just to retain the old value of $2 in linked biblios. For now, I cannot think of a better choice... What could we do else? (If one puts later a new value in auth 040 $f or changes 008/11, the 6XX $2 will be updated or removed accordingly.) 4) A real world example of authority records with 008/11 = 'z' and no 040 $f linked to bibliographic 6XX with 2nd ind. '7' and subfield $2 is the Polish NB bibliographic data: note fields 6XX in https://data.bn.org.pl/api/institutions/bibs.marcxml?id=b1000003108650 vs. example authority record for 'Graficy holenderscy': https://data.bn.org.pl/api/institutions/authorities.marcxml?id=a000000228425... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Janusz Kaczmarek from comment #6)
1) From https://www.loc.gov/marc/authority/ad008.html, section 008/11 = 'z': "A MARC code for the conventions used to formulate the heading *may* be contained in subfield $f (Subject heading/thesaurus conventions) in field 040 (Cataloging Source)". "May" means, IMO, that it is legal to have 008/11 = 'z' and no 040 $f.
Agreed.
2) 008/11 = 'z' in authority implies 2nd ind. = '7' in linked 6XX fields in bibliographic record. And 2nd ind. = '7' implies the presence of $s subfield. (From https://www.loc.gov/marc/bibliographic/bd600.html: " 7 - Source specified in subfield $2 / Subject added entry conforms to a set of subject heading system/thesaurus building rules. The identifying code is given in subfield $2."
You would indeed expect a code there, reading this. Since they could have written "may contain" otherwise.. But that is already interpretation..
3) I agree that removing 040 $f from an authority record while leaving 008/11 = 'z' creates a fuzzy situation but IMO the best heuristics is just to retain the old value of $2 in linked biblios. For now, I cannot think of a better choice... What could we do else? (If one puts later a new value in auth 040 $f or changes 008/11, the 6XX $2 will be updated or removed accordingly.)
The only other choice is removing. But maybe keeping is a bit better. You could still force removal by playing with the auth values as you mention.
4) A real world example of authority records with 008/11 = 'z' and no 040 $f linked to bibliographic 6XX with 2nd ind. '7' and subfield $2 is the Polish NB bibliographic data: note fields 6XX in https://data.bn.org.pl/api/institutions/bibs.marcxml?id=b1000003108650 vs. example authority record for 'Graficy holenderscy': https://data.bn.org.pl/api/institutions/authorities.marcxml?id=a000000228425...
OK Will PQA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183175|0 |1 is obsolete| | --- Comment #8 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 183192 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183192&action=edit Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) Currently, when removing 040 $f from authority record with 008/11 = 'z' (MARC 21), merge function removes the content of $2 subfield in linked 6XX fields, leaving the 6XX $2 subfield empty. This is not correct. We should not have empty subfields in a MARC record. Instead, the old content of the $2 subfield should be retained (if auth 008/11 is still = 'z'). Test plan: ========== 1. Have an authority record with 008/11 = 'z' and 040 $f = 'whatever'. 2. Link the record to a bibliographic 6XX. 3. Edit the authority record, removing 040 $f. 4. Go to bibliographic record and in modal "MARC preview" from Normal view notice that 6XX $2 exists but is empty. This is wrong. 5. Apply the patch ; restart all. 6. Repeat p. 1.-4. Note that the content of 6XX $2 has not been removed. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183176|0 |1 is obsolete| | --- Comment #9 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 183193 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183193&action=edit Bug 40119: Unit tests Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 183194 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183194&action=edit Bug 40119: (QA follow-up) Small additional comment The reference to this bug report may be helpful to understand later why we did so. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |25.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #11 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Nice work everyone! Pushed to main for 25.11 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com --- Comment #12 from Mathieu Saby <mathsabypro@gmail.com> --- Hi Do yo know if a followup is needed for Unimarc? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #13 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Mathieu Saby from comment #12)
Hi Do yo know if a followup is needed for Unimarc?
Dont think so. UNIMARC is easier/more consistent here than MARC21. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #14 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to Marcel de Rooy from comment #13)
(In reply to Mathieu Saby from comment #12)
Hi Do yo know if a followup is needed for Unimarc?
Dont think so. UNIMARC is easier/more consistent here than MARC21.
Me neither. 008/11='z' & 040 $f is a MARC 21 specific solution. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Pushed to stable Version(s)|25.11.00 |25.11.00,25.05.01 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 --- Comment #15 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Nice work everyone! Pushed to 25.05.x for 25.05.03 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable CC| |fridolin.somers@biblibre.co | |m Version(s)|25.11.00,25.05.01 |25.11.00,25.05.01,24.11.08 released in| | --- Comment #16 from Fridolin Somers <fridolin.somers@biblibre.com> --- Pushed to 24.11.x for 24.11.08 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldstable |Needs documenting CC| |wainuiwitikapark@catalyst.n | |et.nz --- Comment #17 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Not backporting to 22.11.x as it wasn't backported to 24.05.x -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org