search

sul-dlss / cocina-models

Cocina repository data model (implemented in Ruby)
https://sul-dlss.github.io/cocina-models/
3 stars 0 forks source link

Validate descriptive metadata value types #376

Closed arcadiafalcone closed 2 years ago

arcadiafalcone commented 2 years ago

Currently most types in descriptive Cocina are controlled because they are mapped from defined MODS types. When users are able to edit native Cocina through spreadsheet upload and download, metadata staff should be able to monitor and mediate the creation of new type values for consistency and interoperability. For that reason, an uploaded spreadsheet's types should be validated by checking against a list of documented types. The validation should be contextual (a note under event would have different accepted types than a note under contributor). The list should be in a format that metadata staff can add to and maintain.

An example of what the list could look like, based on types in current mappings (incomplete): https://drive.google.com/file/d/1KY0783ddLV7tlhnu7Ww0YdWfWfxcPPqw/view?usp=sharing

justinlittman commented 2 years ago

@arcadiafalcone When contributor is at the top level, does that mean every instance of contributor, e.g., Description > contributor and Description > adminMetadata > contributor? (I'm guessing yes.)

But how about note at the top level? I'm guessing that is only intended to be Description > note, not Description > contributor > note.

How are these 2 cases to be distinguished?

arcadiafalcone commented 2 years ago

Each path should include all the options for that path (adminMetadata is incomplete as yet), to avoid having to do that kind of inference. - Deprecated in favor of below.

arcadiafalcone commented 2 years ago

Per discussion with @justinlittman: the type list for the longest applicable path will be used if present, otherwise the top-level type list for that property will be used.

arcadiafalcone commented 2 years ago

Based on data reports, the type validation should be case insensitive.

arcadiafalcone commented 2 years ago

An example of a Cocina description where parallelValue should be ignored when validating type: https://github.com/sul-dlss/dor-services-app/blob/62ad45dc7d90f85a0ffc28089d86828ccb4830d3/spec/services/cocina/mapping/descriptive/mods/name_spec.rb#L194

arcadiafalcone commented 2 years ago

The type validation should treat multiple nested structuralValues as a single structuralValue.

Example from specs: https://github.com/sul-dlss/dor-services-app/blob/a92bb9a529f6611229b9cc9da5f05ac104c7163f/spec/services/cocina/mapping/descriptive/mods/subject_name_spec.rb#L734