[Bug 27087] New: Allow encoding level comparison on record import
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27087 Bug ID: 27087 Summary: Allow encoding level comparison on record import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl The MARC leader position 17 stores a record's encoding level -- # indicates a fully encoded and verified record, with numbers 1-8 indicating increasingly un-encoded and un-verified status. It would be useful to create the option on batch import of only overlaying if the incoming record has a lower (better) encoding level than the existing record. I could see this as either a new option in the "Action if matching record found:" dropdown when staging for import OR as a new variety of match check in the matching rule. -- 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=27087 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26199 -- 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=27087 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Hmm that's interesting. I suppose other uses could be a match check on say the 005 to make sure that the incoming record's value is '>=' to the existing record. -- 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=27087 --- Comment #2 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- So maybe a broader move to allow match checks to use a comparison other than equals? So we'd set a target subfield in the incoming record, a target subfield in the existing record, and a comparison operator? But the values on the encoding level aren't strictly numeric. "#" is the "best" value, followed by 1-8, then "u" for unknown and "z" for not applicable (https://www.loc.gov/marc/bibliographic/bdleader.html). We could hardcode that hierarchy for encoding level, but it seems likely other bits of MARC have comparably idiosyncratic sets of values. Should the match check setup include a mechanism for telling Koha an order of preference for possible values? -- 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=27087 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Andrew Fuerste-Henry from comment #2)
So maybe a broader move to allow match checks to use a comparison other than equals? So we'd set a target subfield in the incoming record, a target subfield in the existing record, and a comparison operator?
I'd say a broader move to allow match points to use comparisons other than equals. (LDR and control fields don't have subfields.)
But the values on the encoding level aren't strictly numeric. "#" is the "best" value, followed by 1-8, then "u" for unknown and "z" for not applicable (https://www.loc.gov/marc/bibliographic/bdleader.html). We could hardcode that hierarchy for encoding level, but it seems likely other bits of MARC have comparably idiosyncratic sets of values. Should the match check setup include a mechanism for telling Koha an order of preference for possible values?
Mmm that's an interesting wrinkle. That's a lot more complicated. Perhaps we should look at plugins for record matching rules. -- 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=27087 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #3)
(In reply to Andrew Fuerste-Henry from comment #2)
So maybe a broader move to allow match checks to use a comparison other than equals? So we'd set a target subfield in the incoming record, a target subfield in the existing record, and a comparison operator?
I'd say a broader move to allow match points to use comparisons other than equals. (LDR and control fields don't have subfields.)
I'm just reviewing my old bug reports and what do you know. I had this idea 5 years ago heh. Bug 15536. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org