Comment 26 for bug 1251394

Thanks for rebasing, Bill.

I think it would be better if the cmf.display_field column defaulted to FALSE and that we supplied some stock cmf definitions that are specifically tuned for display; this would reduce potential requirements conflict between setting up definitions for indexing versus rules for generating human-readable display labels.

For example: the "author" of a work could be taken from author|personal, author|corporate, and so forth. While the set of author|* cmf rows is fine for indexing, a single display field definition that extracts the first mods:name (or however we choose to set it up) would be easier to use.

As a minimal set, I suggest title, author, and publication date (which is particularly interesting given that nowadays both the 260 and 264 must be consulted). We might even go so far as create a 'display' cmf field class.

That's not to say that I think it should be verboten to have a cmf row that's used for both search/browse/facet generation and a display field, but I do think that existing stock definitions should be checked individually before turning on display_field.

One thing that I think would be nice to have but which I don't consider a blocker for merging: a database function to perform a display field reingest that takes bib ID and a list of display field IDs.