grand unified config- csv

[evanwill]

@dcnb @owikle I think maybe we have talked this through before... but devin mentioned something mysterious about theme and config unification, and so I was thinking about it too.

I wonder if config-browse + config-map + config-search + config-table + some theme options all join into big config-metadata?

field,display_name,browse_link,dc_map,schema_map,browse_display,browse_hidden,browse_sort,map_display,map_search,search_index,search_display,table_display,data_export,facets_export,subject_cloud,location_cloud
title,Title,,DCTERMS.title,headline,true,,true,true,true,true,true,true,true,,,
creator,Creator,,DCTERMS.creator,creator,true,,true,true,true,true,true,true,true,true,true,
date,Date Created,,DCTERMS.created,dateCreated,true,,true,true,true,true,true,true,true,true,,
description,Description,,DCTERMS.description,description,,true,,,,true,,,true,,,
subject,Subjects,true,DCTERMS.subject,keywords,true,,,true,true,true,,true,true,true,true,
location,Location,,,contentLocation,true,,,true,true,true,,true,true,true,,true

The file could become like a data dictionary of your metadata fields--just list out all field column names, list what you call them ("display_name"), then choose where they are used. Could add an optional field description to make it a true data dictionary document.

Disadvantage:

• much more complicated CSV
• overwhelming big file with lots of options (rather than scaffolded one at a time approach)
• should list full metadata fields (vs just relevant page display)
• harder to edit, would probably suggest Sheet for novice text editors
• at first seems tied to default pages set up

Advantage:

• less config files
• can provide Sheet template
• document the metadata
• actually easier to add new pages to configure--> rather than having to add a new config- csv, just add a new column!
• theme.yml can be cleaned up to remove most page options to keep it more focused
• makes the mapping of metadata clear center for generating page content