Bug 27087 - Allow encoding level comparison on record import
Summary: Allow encoding level comparison on record import
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-24 15:42 UTC by Andrew Fuerste-Henry
Modified: 2020-12-23 05:02 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2020-11-24 15:42:04 UTC
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.
Comment 1 David Cook 2020-12-18 01:23:12 UTC
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.
Comment 2 Andrew Fuerste-Henry 2020-12-18 13:15:03 UTC
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?
Comment 3 David Cook 2020-12-20 22:51:16 UTC
(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.
Comment 4 David Cook 2020-12-23 05:02:32 UTC
(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.