[Koha-bugs] [Bug 28491] Field 003 in authority records not updated after import

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Sat May 20 02:43:44 CEST 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28491

Phil Ringnalda <phil at chetcolibrary.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at chetcolibrary.org

--- Comment #26 from Phil Ringnalda <phil at chetcolibrary.org> ---
(In reply to Martin Renvoize from comment #23)
> Do you understand how subfield z vs subfield a work here.. my interpretation
> is that a = 'current' (i.e what we're replacing with) and z = 'cancelled'.
> 
> So am I right in thinking.. if we replace 001 + 003 on import we should add
> a 035 with a = (new003)new001 and z (original003)original001.

That idea misses the text in https://www.loc.gov/marc/bibliographic/bd035.html
saying "Control number for the record in a system other than the one whose
control number is contained in field 001 (Control Number), field 010 (Library
of Congress Control Number), or field 016 (National Bibliographic Agency
Control Number)."

Since ours is in 001, we shouldn't be putting it in 035, never mind the part
where $z should indeed mean "the organization in () has said that this number
is canceled or invalid" rather than "I'm personally not currently using this
number in 001."

But, neither of those mean we can't push ahead with misusing 035, since the
entire idea requires misuse.

If the original 003 is a national library and the original 001 is in either 010
or 016, then putting it in 035 is also wrong. However, the existence of an 010
doesn't mean a record came from the LC, and unless we delete existing 035s
before adding ours, the existence of an 035 $a(OCoLC) doesn't mean it came from
OCLC. In fact, for a name heading first created by a NACO cataloger using OCLC,
the OCLC record has an 010 but no 035 because OCLC's control number is in 001,
and the LC record has an OCLC 035 from when LC imported it.

And there's no meaning to the order of fields, and no 035 subfield which in any
way says "this is the one that means something about where a Koha user imported
this record from" so we would either have to use a very fragile system of
saying "the source of the record is in the (first|last) 035, unless one of your
employees or an outside contractor doing authority control didn't know that
special fact and put one (before|after) it" or be overly-aggressive and delete
every existing 035 before adding our One True 035.

Or, we could do what the spec really wants, and define 935
$a(original003)original001 as being (within a Koha instance) the source from
which we imported a record, and then people would only have to look in two
places: if 935 exists, it's where it came from, if not and 003 is not your
marcorgcode (or, not any of your marcorgcodes if you have them per-library)
then it's an old import and the 003 is where it came from, if not then 003 is
your marcorgcode and you're where it came from. We would have to clobber any
existing 935, whether it was one of ours coming from an import from another
Koha instance or one from elsewhere with a different meaning, but hey, that's
how locally-defined works.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list