Versions Compared

Version Old Version 11 New Version 12
Changes made by

Khalilah Gambrell

Khalilah Gambrell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Page status:

Status
colourYellow
titleIn progress

What is MARC record validation 

...

  • Initial development: Validation will be implemented for create/derive/edit MARC bib and authority records. In future releases, this implementation should span to support
    • Data import (support MARC bib and MARC authority records only)
    • Data export (support MARC bib and MARC authority records only)
    • MARC holdings support via quickMARC/Data import/Data export 
  • Configuration 
    • Each tenant will have a default MARC bib record validation that can be customized per workflow. Initial development: Create/Derive/Edit MARC bib via quickMARC
    • Each tenant will have a default MARC authority record validation that can be customized per workflow. Initial development: Create/Edit MARC authority via quickMARC
    • Initial implementation - No UI will be provided. Future releases will support a UI to customize validation rules. 
  • Localization and Unicode support 
  • Enhanced Consortia Support  
  • Release upgrade
    • When initial development is complete and released, there should be minimal impact to existing libraries. It should not require multiple hours to update records. 
    • It should not require significant work for hosting providers. 
    • Ideally existing libraries will not be asked to update all bib and authority records once this capability is released. 
  • Migrations from one ILS to FOLIO
    • Customizations should be setup prior to loading records
    • If loading records outside of data import, then we need to assume that MARC bib/authority validation is bypassed and if so, we need to ensure that the user can view and edit the record when the record has errors. 
  • Changing rules expectations 
    • Ideally a global change to MARC bib/authority validation rules can be done easily and not require an update all bib and authority records. 
    • A tenant should be able to customize MARC bib/authority validation rules at anytime AND does not require an update all bib and authority records. 
    • If the tenant updates a rule and it now conflicts with existing records then we need to ensure that the user can view and edit the record when the record has errors. 
  • Data import 
    • Initial development: No impact (includes single record import) 
    • If the imported record conflicts with validation rules then we need to ensure that the user can view and edit the record when the record has errors. 
  • Reporting
    • TBD
  •  Performance
    • No change to performance when Create/Derive/Edit via quickMARC

Phased approach approach

ReleaseDeliverables
Quesnelia
  • Define technical approach for phase 1 to create/edit/derive MARC bib/auth via quickMARC
  • Implement mandatory MARC bib rules – structural based on LOC documentation
  • Implement mandatory MARC authority rules – structural based on LOC documentation
Ramsons
  • Implement technical approach for phase 1 to create/edit/derive MARC bib/auth via quickMARC
    • Includes ECS support 
    • Global MARC bib / MARC authority rules validation via config file/API endpoint
    • Customize MARC bib/MARC authority rules validation per tenant via config file/API endpoint 
  • Continue to implement mandatory MARC bib rules – structural based on LOC documentation
  • Continue to implement mandatory MARC authority rules – structural based on LOC documentation
Sunflower

Complete implementation (phase 1) 

  • Logging 
  • Reporting 

Technical Design High-Level Requirements 

  • The tech design should not be MARC centric meaning that it should be flexible enough to assign a set of validation rules per record type + format. 
  • The tech design should also allow for any flow that creates/updates/export MARC to opt-in to using these validation rules (this includes data import and data export) 
  • Technical design will focus on MARC bibliographic and MARC authority records. MARC holdings will be handled at a later release. 

...

  •  

Feature Matrix 


FeatureDescription

Global MARC bib rules validation that includes 

  • MARC tags (repeatable/non-repeatable) 
  • MARC tags (required/not required) 
  • MARC indicators (required/not required)
  • MARC subfields (repeatable/non-repeatable) 
  • MARC subfields (required/not required)
  • MARC subfield values?  
  • MARC fixed fields 



Global MARC authority rules validation that includes 

  • MARC tags (repeatable/non-repeatable) 
  • MARC tags (required/not required) 
  • MARC indicators (required/not required)
  • MARC subfields (repeatable/non-repeatable) 
  • MARC subfields (required/not required)
  • MARC subfield values? 
  • MARC fixed fields 



Allow a tenant to clone/customize MARC bib global rules validation to create/edit/derive via quickMARC  




Allow a tenant to clone/customize MARC authority global rules validation to create/edit via quickMARC












Supporting Materials 

Market Intelligence


Review Later

FeaturesNotesStatus
Review current validation rules

Highlight field user is on.

Handle literal $

Change Leader

Change 008

Change 007

Change 006

Change 852

Identify a default MARC record validation - bib (allow libraries to change)

Identify a default MARC record validation - holdings (allow libraries to change)

Identify a default MARC record validation - authority (allow libraries to change)

Apply autosuggest to TBD fields

Generate MARC record validation reports/logs

Support the following types of error validation

  • Errors that cannot save record 
  • Errors that still allow for record to be saved 


Support additional statuses (SRS/quickMARC)

Only maintain last 3 versions of record in SRS 

Additional shortcut keys

Contextual field help

Undo edits (field level)

Undo edits (record level) 

Define workflow to use MARCedit to make batch changes 

Supporting Materials 

Market Intelligence