Bug 37364 - Improve creation of 773 fields for item bundles regarding MARC21 245 and 264
Summary: Improve creation of 773 fields for item bundles regarding MARC21 245 and 264
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Martin Renvoize (ashimema)
QA Contact: Testopia
URL:
Keywords:
Depends on: 29560
Blocks: 37305
  Show dependency treegraph
 
Reported: 2024-07-15 15:06 UTC by Katrin Fischer
Modified: 2024-10-08 15:45 UTC (History)
4 users (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
Bug 37364: Add requested RDA handling to generate_marc_host_field (1.96 KB, patch)
2024-07-17 08:45 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 37364: Add requested RDA handling to generate_marc_host_field (1.94 KB, patch)
2024-07-17 08:58 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 37364: Unit tests (3.28 KB, patch)
2024-07-17 08:58 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2024-07-15 15:06:10 UTC
1) I think we should adjust to also take RDA records using 264 into account here. At least for us these are now the majority of records.

+        # Publication
+        if ( $host_field = $marc_host->field('260') ) {
+            my $s = $host_field->as_string('abc');
+            if ($s) {
+                $sfd{d} = $s;
+            }
+        }

773$d is not repeatable, so we should avoid to create 2 entries. Maybe check for existence of 264 first and then fallback to 260 if the first is not found?

260 and 264 are both repeatable. I assume this either uses the first or last entry - can you tell? 

Ideally it might be good to prefer the entry with first indicator = 3 (current/latest), if it exists: https://www.loc.gov/marc/bibliographic/bd264.html


2) This should take $n$p into account as well, as otherwise a multi-part work will not be distinguishable from the title:

+        # Title
+        if ( $host_field = $marc_host->field('245') ) {
+            my $s = $host_field->as_string('ab');
+            if ($s) {
+                $sfd{t} = $s;
+            }
+        }

I think this could just be changed to: abnp for the subfield list.
Comment 1 Heather 2024-07-16 15:39:18 UTC
> 773$d is not repeatable, so we should avoid to create 2 entries. Maybe check
> for existence of 264 first and then fallback to 260 if the first is not
> found?

This should work!
 
> 260 and 264 are both repeatable. I assume this either uses the first or last
> entry - can you tell? 

Yes--both the 260 and the 264 would have first indicator = 3 for "current, latest."
 
> Ideally it might be good to prefer the entry with first indicator = 3
> (current/latest), if it exists...

Yes--this would work.  Examples are here, on p.43: 
https://www.loc.gov/aba/pcc/conser/CCM/module35.pdf
E.g.:
264 #1 $3 1990-1994: $a Salem, N.H. : $b Butterworth Legal 
Publishers
264 21 $3 1995-<1996>: $a Charlottesville, VA : $b Michie
264 21 $3 <1998>-1999: $a Charlottesville, VA : $b LEXIS Law Pub.
264 31 $3 2000- : $a Huntington, NY : $b Juris Pub., $c c1990-

> 2) This should take $n$p into account as well, as otherwise a multi-part
> work will not be distinguishable from the title:

Yes!!!

> I think this could just be changed to: abnp for the subfield list.

This order can be different in the 245, so IMO should be preserved in the 773, otherwise the title will make no sense, e.g. this 245's order is apnpb (from the MARC21 standard):
245	00$aDeutsche Bibliographie.$pWöchentliches Verzeichnis.$nReihe B,$pBeilage, Erscheinungen ausserhalb des Verlagsbuchhandels :$bAmtsblatt der Deutschen Bibliothek.

So can the order of the subfields in the 245 be preserved in the created 773?
--h2
Comment 2 Katrin Fischer 2024-07-17 07:51:30 UTC
Hi Heather, I forgot that n and p are also repeatable... Not sure if keeping sequence is hard/easy, but we can at least ask for it :)
Comment 3 Martin Renvoize (ashimema) 2024-07-17 08:37:37 UTC
I've got a patch for the 260/264 stuff and I'm working on the 245 now.

Order could be fun, need to also take punctuation into consideration given recent chat's.  I can maintain order fairly trivially I think, though repeats and punctuation add a little extra challenge.
Comment 4 Katrin Fischer 2024-07-17 08:38:30 UTC
I think as Koha at the moment expects the punctuation to be there, you only need to make sure that we have a space between the subfields and otherwise the string can be unchanged.
Comment 5 Martin Renvoize (ashimema) 2024-07-17 08:42:59 UTC
Ooohh.. ordering is already correct:

> as_string( [$subfields] [, $delimiter] )
>Returns a string of all subfields run together. A space is added to the result between each subfield, unless the delimiter parameter is passed. The tag number and subfield character are not included.

>Subfields appear in the output string in the order in which they occur in the field.

>If $subfields is specified, then only those subfields will be included.
Comment 6 Martin Renvoize (ashimema) 2024-07-17 08:45:45 UTC
Created attachment 169075 [details] [review]
Bug 37364: Add requested RDA handling to generate_marc_host_field

This patch adds handling for the 264 field in precedence to the 260 for
the generate_marc_host_field method and also adds subfields n and p to
the 245 handling.
Comment 7 Martin Renvoize (ashimema) 2024-07-17 08:58:17 UTC
Created attachment 169076 [details] [review]
Bug 37364: Add requested RDA handling to generate_marc_host_field

This patch adds handling for the 264 field in precedence to the 260 for
the generate_marc_host_field method and also adds subfields n and p to
the 245 handling.
Comment 8 Martin Renvoize (ashimema) 2024-07-17 08:58:20 UTC
Created attachment 169077 [details] [review]
Bug 37364: Unit tests