Versions Compared

Key

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

Page status:

Status
colourYellow
titleIn progress

Table of Contents

What is MARC record validation 

...

  • Initial development: Validation will be implemented for create/derive/edit MARC bib and authority records via quickMARC UI.
  • In future releases, this implementation should extend 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 
    • Bulk-edit support 
  • 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. 
    • The library/tenant will not be able to customize/override global MARC bib record validation rules for the following fields: Leader, 001, 005, 999 ff $s / $i, 006, 007, 008. Future implementation - we may allow for customization/override of select Leader/006/007/008 positions. 
  • 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 existing 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 add/update/delete to MARC bib/authority validation rules can be done easily and not require an update to 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 to all bib and authority records. 
    • If the tenant adds/updates/deletes 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

...

  • 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 + per workflow. 
  • 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. 
  • See MARC validation - Logic for rules to be implemented for Phase 1. 

...

Proposed approach - (

...

draft

FeatureDescription / Jira issue(s)Notes 

Tenant level - Configure MARC bib rules validation that supports logic outlined - MARC validation - Logic

  • Define Global validation rules
  • Define which Global validation rules cannot be overridden by a tenant 
  • Specify which validation rule(s) can be overridden by a tenant 
  • Specify which validation rule(s) prevents user from saving record OR just warns a user and allows save to continue
  • Set Help documentation link
ReleaseDeliverablesJira Requirements
Quesnelia
  • Phase 1 - Define technical approach when creating/editing/deriving MARC bib/auth via quickMARC that also accounts for ECS.
  • Implement several related MARC validation issues
MARC validation - Logic

LDR contextual help

RamsonsSunflower
  • Phase 1 - Complete implementation 
    • View Errors that do not prevent save
    • Additional Logging 
  • MARC punctuation handling 
  • Expose authority control mapping rules?
  • Remove subfield 9 logic on linkable fields? 
Trillium

Phase 2 - ISBN/ISSN validation  (can the existing tool be used?)

Phase 2 - Reporting (Lists app?) 

Umbrellaleaf

Phase 3a  - Data import support (including single record import)

Vetch

Phase 3b  - Data import support (including single record import) 

Feature Matrix - Phase 1

  • Field help documentation 
  • LCCN structure validation and duplication checking.
    • Jira Legacy
      serverSystem Jira
columnIdscolumnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    • serverId01505d01-b853-3c2e-90f1-ee9b165564fc
      key
MODQM-390

quickMARC front-end work 

  • Display error and warn messaging 
  • Option to validate 
  • Link(s) to help documentation 

Tenant level - Configure MARC authority rules validation that supports logic outlined - MARC validation - Logic

  • Define Global validation rules 
  • Define which Global validation rules cannot be overridden by a tenant
  • Specify which validation rule(s) can be overridden by a tenant 
  • Specify which validation rule(s) prevents user from saving record OR just warns a user and allows save to continue
  • Set Help documentation link
      • UXPROD-4537
      • Jira Legacy
        serverSystem Jira
    columnIds
    issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutioncolumnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      • serverId01505d01-b853-3c2e-90f1-ee9b165564fc
        key
    MODQM
      • UXPROD-
    391

    Jira Legacy
    serverSystem Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyMODQM-393

    quickMARC front-end work 

    • Display error and warn messaging 
    • Option to validate 
    • Link(s) to help documentation 

    Allow a tenant to create/modify validation rules for local bib fields or fields not outlined in LOC MARC documentation 

      • Repeatability
      • Valid values (indicators, subfields)
      • Required/optional

    Allow a tenant to create/modify validation rules for local authority fields or fields not outlined in LOC MARC documentation 

      • Repeatability
      • Valid values (indicators, subfields)
      • Required/optional
    Allow a user to view and edit a MARC bib/MARC authority that bypasses rules validation and has errors. Examples: a record imported via data import or direct to the db. 

    Allow a tenant to delete validation rules for local bib fields or fields not outlined in LOC MARC documentation 

    Allow a tenant to delete validation rules for local authority fields or fields not outlined in LOC MARC documentation 

    Authority control subject validation 

    Frontend dev

    • quickMARC display error messaging 
    Ability to export validation rules in a json/text file 
      • 4060
    Sunflower (TBD)
    Trillium (TBD)
    • ISBN/ISSN validation 
    • Expose authority control mapping rules?
    Umbrellaleaf  (TBD)
    • Data import support (including single record import)
    Vetch (TBD)
    • Data import support (including single record import) 

    Supporting Materials 

    ...