Compare to [to_semantic_values](https://github.com/projectblacklight/blacklight/blob/a5282a0b077a51b387f0d501c03ce960f422f2ea/lib/blacklight/solr/document.rb#L136)

So the idea of `to_semantic_fields` was that it was a method on SolrDocument that would return a hash of symbols for semantics to values. 
 
For instance:
 
    some_doc.to_semantic_fields   # =>  {:title => "A Very Fine Book", :author => "John Smith"}

The default implementation might be to take these values from Solr stored fields. Perhaps Solr stored fields as defined in config, which stored field was for :title, which for :author, etc.  

But recall that the Document extension stuff adds in additional modules to SolrDocument, on a document-by-document basis.  

So then, for example, a MARC-based document (which MARC source available at display-time) might have a module mixed in, which redefined `to_semantic_values` to look up :title, :author (and any other standardized semantic terms) directly from the MARC record, rather than from Solr stored values. 

Individual localized apps could add their own extensions to look up :author and :title from their own places, perhaps different than the Blacklight standard, whether for MARC or Solr stored fields or what. 

But the caller can just do `solr_document.to_semantic_fields[:author]` and get an author string, or title string, etc. It doesn't need to know about the implementation of where these come from, which may be different even for differnet documents in a single result set, as well as may be customized by add-on gems or local applications. 

This is exactly what the [Atom response does](https://github.com/projectblacklight/blacklight/blob/a5282a0b077a51b387f0d501c03ce960f422f2ea/app/views/catalog/index.atom.builder#L50) to look up a title and author for a doc, to include in the atom results. 

So the same thing could be done with the html5 microdata output.  You need a :title or :author -- or whatever else you need, that we establish as a conventional `:term_name`, you look it up in `to_semantic_values`.  Or it could be an entirely different method, `to_schema_org_values` I guess too, using the same technique. But enough of the values are going to be in common with the existing `to_semantic_values`, and I can't think of any case it would cause a conflict, to just use it and extend it with more keys. 

It could for example be extended with a key :schema_org_type that by default returned, say, `http://schema.org/Thing`, but certain types of documents might provide their own implementations that looked up a more specific type, from a Solr stored field, from MARC, from whatever.  Or an individual app that knew everything in it was a movie might over-ride (again using the techniques from the doc extension framework) to just hard-code to `http://schema.org/VideoObject` or whatever. 

Does this make sense?