Summary: | Allow encoding level comparison on record import | ||
---|---|---|---|
Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrew> |
Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, m.de.rooy |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26199 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Andrew Fuerste-Henry
2020-11-24 15:42:04 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. 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? (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. (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. |