Bug 40119 - Merge should not leave empty 6XX subfield $2 (MARC 21)
Summary: Merge should not leave empty 6XX subfield $2 (MARC 21)
Status: Pushed to stable
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Janusz Kaczmarek
QA Contact: Marcel de Rooy
URL:
Keywords: release-notes-needed
Depends on:
Blocks:
 
Reported: 2025-06-11 14:12 UTC by Janusz Kaczmarek
Modified: 2025-06-22 21:47 UTC (History)
5 users (show)

See Also:
GIT URL:
Change sponsored?: Sponsored
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
25.11.00,25.05.01
Circulation function:


Attachments
Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) (1.76 KB, patch)
2025-06-11 14:23 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 40119: Unit tests (2.89 KB, patch)
2025-06-11 14:23 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) (1.81 KB, patch)
2025-06-11 18:21 UTC, Roman Dolny
Details | Diff | Splinter Review
Bug 40119: Unit tests (2.94 KB, patch)
2025-06-11 18:21 UTC, Roman Dolny
Details | Diff | Splinter Review
Bug 40119: Merge should not leave empty 6XX subfield $2 (MARC 21) (1.90 KB, patch)
2025-06-12 09:17 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 40119: Unit tests (3.03 KB, patch)
2025-06-12 09:17 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 40119: (QA follow-up) Small additional comment (1.16 KB, patch)
2025-06-12 09:17 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Janusz Kaczmarek 2025-06-11 14:12:29 UTC
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.
Comment 1 Janusz Kaczmarek 2025-06-11 14:23:47 UTC
Created attachment 183165 [details] [review]
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
Comment 2 Janusz Kaczmarek 2025-06-11 14:23:49 UTC
Created attachment 183166 [details] [review]
Bug 40119: Unit tests
Comment 3 Roman Dolny 2025-06-11 18:21:24 UTC
Created attachment 183175 [details] [review]
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>
Comment 4 Roman Dolny 2025-06-11 18:21:27 UTC
Created attachment 183176 [details] [review]
Bug 40119: Unit tests

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Comment 5 Marcel de Rooy 2025-06-12 07:59:48 UTC
(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)?
Comment 6 Janusz Kaczmarek 2025-06-12 08:35:11 UTC
(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=a0000002284250
Comment 7 Marcel de Rooy 2025-06-12 09:08:50 UTC
(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=a0000002284250

OK

Will PQA
Comment 8 Marcel de Rooy 2025-06-12 09:17:37 UTC
Created attachment 183192 [details] [review]
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>
Comment 9 Marcel de Rooy 2025-06-12 09:17:39 UTC
Created attachment 183193 [details] [review]
Bug 40119: Unit tests

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 10 Marcel de Rooy 2025-06-12 09:17:41 UTC
Created attachment 183194 [details] [review]
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>
Comment 11 Lucas Gass (lukeg) 2025-06-13 19:31:56 UTC
Nice work everyone!

Pushed to main for 25.11
Comment 12 Mathieu Saby 2025-06-16 10:38:19 UTC
Hi
Do yo know if a followup is needed for Unimarc?
Comment 13 Marcel de Rooy 2025-06-16 10:45:48 UTC
(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.
Comment 14 Janusz Kaczmarek 2025-06-16 11:12:04 UTC
(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.
Comment 15 Paul Derscheid 2025-06-22 21:47:36 UTC
Nice work everyone!

Pushed to 25.05.x for 25.05.03