From Job / Record GUI, identify select fields and apply job-wide

[ghukill]

From within a Job, or perhaps a record field, or both, allow user to associate a parsed ES field with a known type of field important for DPLA records.

e.g. If a user knows that thumbnail URLs are usually parsed to mods_location_url_@access_preview in ES, allow them to associate this field with a parameter somewhere in the Job that will faciliate showing that thumbnail on Record page (or Job DT view!).

Do the same for other important fields:

• thumbnail (e.g. mods_location_url_@access_preview)
• access URL (e.g. mods_location_url_@usage_primary )
• title (e.g. mods_titleInfo_title)
• description (e.g. mods_abstract )

This makes sense at the Job level, as a Transform job might change the mapping.

These could be stored as JSON in Job table, perhaps a field like dpla_mappings? Not ideal, as would require JSON parsing in and out.

What is known, are the target fields (see above), but these might shift or change. These fields are useful only insofar they are used to add information to the preview pages, or are used in analysis.

This begins to dip into a DPLA mapping, as separate from ES mapping/indexing, which is primarily a rough comb for QAing records before DPLA mapping.

Holding off on a decision for now, but might be groundwork for exploring DPLA mapping options.

[ghukill]

Consider this situation from a PublishedRecords view, where the URL for access is split between two parsed fields:

mods_location_url_@usage_primary (38,269)
mods_location_url_@usage_primary_@access_object_in_context (1,422)

The 1,422 are from Western, and parse slightly different. Would it make sense to allow for multiple field mapping? n:1?

[ghukill]

Some experimental progress on this:

• new DPLAJobMap model
  • with default None values for a handful of useful fields from here
• indexed fields table identifies mappings, shows in table
• Record page identifiers mappings, shows mapped DPLA fields at top (including thumbnail)

Next steps:

• UI for mapping fields
  • dropdown in indexed fields table from Job details?
  • associate at the field details level, one-by-one?
• for sanity's sake, will need to be able to save mappings
  • current DPLAJobMap instances are associated with job, but when hypothetically selecting a saved mapping, could select a previously used one? do they need a name?

Selecting mappings from previous jobs solves some problems, like how to propagate from job-to-job in a natural harvest --> transform --> merge (maybe) --> publish workflow. But, because they are linked to job, you run the risk of it disappearing if you delete that job.

[ghukill]

After some conversations, the point was made that it might make sense to "pin" this DPLA mapping to the transformation, and not the Job.

Pros

• would persist if jobs deleted
• after a transform, mappings would already be in place (very nice)
• could tweak mapping from within a job (field-by-field), which would save to the more global mapping

Cons

• what about jobs that are not transforms? would selecting a mapping from a transform be awkward? is that, in fact, pointing at some other underlying issue?
• if mapping includes fields that are not present for a job, but were then mapped from a job on-the-fly, the user would unwittingly be removing a mapping they could not see

[ghukill]

For the time being, leaving "pinned" to Job. Might revisit when looking into actual DPLA mapping with Ingestion3 code.