...
- MARC field protections are only invoked if a MARC Update action is included in the job profile.
- Based on feedback from the community, consider changing the behavior so that the field protections are invoked automatically/implicitly.
- When evaluating data in a subfield, MARC field protections are not case-sensitive. For example $a NcD, $a NCD, $a Ncd, $a ncd, $a ncD would all be considered equivalent and duplicates of each other.
- After testing and early usage, if the community decides that the field protections must take upper and lower case into account for data in subfields, consider changing the behavior so that the field protections are case-sensitive rather than case-insensitive
- For data in a subfield, the field protection is based on the entire data string.
- Consider supporting wildcards, begins, ends, contains in the future.
- One master list of MARC field protections is maintained in Settings/Data import.
- Per conversation with the MARC Holdings libraries, MARC field protections will NOT be applied to MARC Holdings records.
- Unless/until a future use case is identified that necessitates differentiation, this same list of field protections will be used for MARC Bibliographic and MARC Authority records.
- MARC field protections are controlled at the tenant level, though field protections can be overridden for a particular action profile/job profile.
- Based on feedback from the community, consider adding the ability to include additional field protections in individual job profiles, for MARC fields that are used infrequently or do not normally need to be protected.
- Consider supporting wildcards, begins, ends, contains in the future.
- Question for librarians: can we assume that LDR, 002-009 fields do not need field protection? Per MM SIG and DI subgroup, March 2022: fields 006 and 007 should allow field protection, but none of the other control fields (LDR, 002, 003, 004, 005, 008, 009)
...