| Table of Contents |
|---|
Background
- First iteration created in MODDICONV-137
- Bugfixes required and will be delivered in Lotus, so this page has been created to document expected behavior for 1) Protecting MARC field and then 2) Overriding MARC field protections. (overrides not yet documented here)
...
Current constraints of MARC Field Protections:
- 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.
- 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
- 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
- Per conversation with the MARC Holdings libraries, MARC field protections will NOT be applied to MARC Holdings 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.
- For data in a subfield, the field protection is based on the entire data string.
- 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)
...
- Example 1
- Existing: 982 $a 20210531 $a 20210602 $5 NcD
- Incoming: 982 1 1 $a 20210531 $a 20210602
- Retain existing 982; add incoming 982 (since indicators are different)
- Example 2
- Existing:
- 050 $a MT123 $b .T68 2021 $5 NcD
- 050 $a MT123 $b .T68 2022
- 982 $a 20210531 $a 20210602 $5 NcD
- 982 2 2 $z 20210531
- Incoming: no 050 or 982
- Retain existing 050 with $5 NcD; discard existing 050 without $5 NcD; retain both 982s
- Existing:
MARC field protection
...
scenarios
From Olamide Kolawole
...
...
Scenario 1: MARC Field Entry Is Protected
- Given 5 qualifiers: [Field Number], [Indicator 1], [Indicator 2], [Subfield], [Data]
...
- And each qualifier can have a wildcard(*) as its value to denote a criteria match of any value
...
- # definition of each qualifier should be added here
...
- When a MARC Field entry components matches all 5
...
- qualifiers
...
- Then the MARC Field is protected
Scenario 2: MARC Update When an entry already exists exactly, NON-REPEATING
- Given a MARC field entry that is exists and is protected and is non-repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When any incoming MARC field entry is exactly the same as the protected existing entry
...
- Then the incoming MARC field will be discarded
Scenario 3: MARC Update When an entry already exists exactly, REPEATING
- Given a MARC field entry that is exists and is protected and is repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When any incoming MARC field entry is exactly the same as the protected existing entry
...
- Then the incoming MARC field will be discarded
Scenario 4: MARC Update when no entries are the same, NON-REPEATING
- Given a MARC field entry that is exists and is protected and is non-repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When no MARC entry in the collection is the same as the existing MARC field entry
...
- Then the end state will include the existing protected MARC field entry and the collection of incoming MARC field entries
Scenario 5: MARC Update when no entries are the same, REPEATING
- Given a MARC field entry that is exists and is protected and is repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When no MARC entry in the collection is the same as the existing MARC field entry
...
- Then the end state will include the existing protected MARC field entry and the collection of incoming MARC field entries
Scenario 6: MARC Update when the one incoming is the same, NON-REPEATING
- Given a MARC field entry that is exists and is protected and is non-repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When at least one field entry in the collection has the same field number as the existing MARC field entry but the whole field entry is not the same
...
- Then the end state will include the existing protected MARC field entry and field entries in the collection that do not have the same field number as the existing protected MARC field
Scenario 7: MARC Update when at least one incoming is the same, REPEATING
- Given a MARC field entry that is exists and is protected and is repeating
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- When at least one field entry in the collection has the same field number as the existing MARC field entry but the whole field entry is not the same
...
- Then the end state will include the existing protected MARC field entry and the collection of the incoming MARC field entries
Scenario 8: MARC Update when there are no existing records
- Given no MARC field entry exists
...
- And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
...
- Then the end state will include the collection of the incoming MARC field entries
...