search

projectblacklight / blacklight

Blacklight provides a discovery interface for any Solr (http://lucene.apache.org/solr) index.
http://projectblacklight.org/
Other
757 stars 256 forks source link

Feature parity between ruby-land Semantic Fields and Solr fields #688

Open cbeer opened 10 years ago

cbeer commented 10 years ago

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

atz commented 7 years ago

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?

atz commented 7 years ago

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.