Versions Compared

Key

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

...

  • 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

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

Ramsons
Sunflower
  • LCCN structure validation
  • MARC punctuation handling (determine a front-end approach) - stretch
  • Authority control - Subject validation (stretch) 
  • Expose authority control mapping rules?
  • Remove subfield 9 logic on linkable fields? 
  • Handle deprecated fields - https://www.loc.gov/marc/bibliographic/bdapndxh.html

Trillium

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

UI configuration 

Reporting (Lists app?) 


Umbrellaleaf

Data import support (including single record import)


Vetch

Data import support (including single record import) 


...