projectblacklight
Feature parity between ruby-land Semantic Fields and Solr fields
I think it makes sense, though, to add a new ticket to provide some feature parity between the semantic fields and the solr fields, all the better if they can be used interchangeably with some of the templates and solr configs (why shouldn't you be able to use add_index_field with a field that is made available in ruby-land? I can't think of a problem off-hand..)
Context:
The use case for the architecture I'm trying to describe, using the doc extension sutff, is providing for more flexibliity, so schema.org values do not have to be in Solr stored fields, but can come from other places. For a SolrDocument with an associated MARC record, the schema.org values could be looked up from inside the MARC record. For a SolrDocument with an associated oia-dc XML, the schema.org values could be looked up from the XML. Etc. There could still be a default 'base' implementation that looked up the values from Solr stored fields.
In my own app, I simply don't keep title or author etc in Solr stored fields. I have very few Solr stored fields. I instead extract values like that from the MARC record at display time, rather than writing code to extract the values from the MARC record at index-time and store them in stored fields. This is because the code to get that stuff out of MARC is pretty complicated; I wanted to do it in ruby (rather than SolrMarc, when I was using that), and I also wanted to be able to change this logic without doing a re-index.
From https://github.com/projectblacklight/blacklight/pull/680
This sounds like a more VuFind-like approach, where the binary record is available during presentation.
We appear to moving in the opposite direction, specifically motivated by the desire for consistency between discoverability (search filtering), faceting and presentation. Perhaps we can reexamine whether we think it is still useful to pursue this architecture. Can we identify who was advocating for this initially?
I guess I'll go ahead and say my disposition is to close this. ActiveFedora experimented and essentially failed trying to model interchangeable document-of-record and comparable solrdoc-field accessors.