https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40119
--- Comment #7 from Marcel de Rooy <[email protected]> --- (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 -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
