A proposed patch to provide a way to configure 'semantic' mappings for solr stored fields, from a semi-controlled vocabulary. For instance, to configure that a :title value is provided from the stored field "title_display".

To explain why this is useful, consider CODEBASE-77, about RSS feeds. Currently as of this writing, our rss-generating template assumes that title and author can be found in certain hard-coded solr stored field names. This is obviously inappropriate, it needs to be configurable.

We _could_ provide configuration aimed at the "presentation" of RSS. rss_title_field = "title_display" or something. That would be in line with the existing presentation-aimed configuration related to stored fields we have: We have configuration for labels to use for certain fields (config[:show_fields][:labels]); and we have also have config related to what field to use to put in a certain spot on a certain screen (config[:show][:html_title], config[:show][:heading], config[:index][:show_link] ).

However, this threatens to become a voluminous list of presentation-level config parameters -- that in many cases are configured to the same thing -- for example in default out-of-the-box, config[:show][:html_title] == config[:show][:heading] == config[:index][:show_link] == "title_display".

It occurs to me that semantic-level configuration could provide a more efficient, easier to config, re-useable and extensible framework for this. If there were a way to config which stored field were :title, this could be used by the RSS generation, by hypothetical Atom generation, by hypothetical OAI-PM generation, and possibly even as the default for things like config[:show][:html_title]. Presentation-level config could still be provided for certain views when neccesary, but in many cases shared semantic-level config could suffice, keeping things simple.

Proposal in code:

First you would describe your semantic mappings, something like:

  SolrDocument.field_semantics = {
    :title => "title_display",
    :author => "author_display",
    :publisher => "publisher_display",
    :language => "language_facet"
  }

Note that the 'semantics' are just arbitrary symbols, so this leaves flexibility for extensions to define their own that you could still house there.

Now, SolrDocument has a method that will actually take that config and produce a hash where the values are actual values from the document

someDocument.to_semantic_values => {
   :title => "Title of the book",
   :author => "Author of the book"
}

Etc. Client code will actualy never look at the config values, only SolrDocument itself looks there, client code (like an RSS view), calls someDocument.to_semantic_values[:title] for instance.

This means that the to_semantic_values method is available for Solr Document Extensions to provide custom additions or modifications to, if needed.

Code in progress is/will be in: http://github.com/jrochkind/blacklight/tree/semantic_fields