Here is my take on this, based on the Staff Interface Enhancement Working Group’s recommendations and my own assessment of practicality. Ideally, anything that can be selectable for display can also be selectable for sort.
Defaults are noted by a *. I decided to only do this for the three main record types and multi. Anything else we can work to define defaults a little later on, but they probably don’t need to be customizable in the preferences View.
Accession
• title*
• identifier*
• accession date*
• acquisition type
• resource type
• restrictions apply
• publish
• access restrictions
• use restrictions
• dates*
o the date displayed should be the collection level inclusive dates (or single, or bulk if inclusive dates do not exist)
• extents*
o the extent displayed should be the collection level Whole extent only
o If there is no single Whole, then include all parts so the entire extent is listed [this is the Staff Interface group’s recommendation – may need more evaluation]
• processing priority
• processors
• audit info
• Is language now here too? – if so language (will be a sub-record with Lora’s changes)
Resource
• Title*
• identifier*
• level of description*
• resource type
• language (will be a sub-record with Lora’s changes)
• publish
• restrictions apply
• dates*
o the date displayed should be the collection level inclusive dates (or single, or bulk if inclusive dates do not exist)
• extents*
o the extent displayed should be the collection level Whole extent only
o If there is no single Whole, then include all parts so the entire extent is listed [this is the Staff Interface group’s recommendation – may need more evaluation]
• ead_id
• finding aid status
• processing priority
• processors
• audit info
Digital Object
• title*
• identifier*
• publish
• VRA Core level
• digital object type
• language (will be a sub-record with Lora’s changes)
• restrictions
• dates
o the date displayed should be the collection level inclusive dates (or single, or bulk if inclusive dates do not exist)
• extents
o the extent displayed should be the collection level Whole extent only
o If there is no single Whole, then include all parts so the entire extent is listed [this is the Staff Interface group’s recommendation – may need more evaluation]
• audit info
Multi
• record type*
• title*
• found in*
• identifier* (some nuance needed with this, i.e. if it’s an archival object, what identifier shows?)
• audit info
• dates*
o for resources, accessions, digital objects, the date displayed should be the collection level inclusive dates (or single, or bulk if inclusive dates do not exist); for archival objects digital object components, this should follow a similar pattern, but localized to the object
• extents
o for resources, accessions, digital objects, the extent displayed should be the collection level Whole extent only
o If there is no single Whole, then include all parts so the entire extent is listed
Test branch available at http://wiprefds.lyrtech.org/staff/
This appears to work as designed. Looks like there’s a translation missing, though
One thing to think about for future iterations. The table view in search/browse is getting very crowded. Not sure if there’s any impetus to think about a more Google like search results view as in the PUI? At the expense of making the page longer, that would allow for more information to be displayed and potentially make the information easier to parse. We’ve already done that at Dartmouth because we’re enhancing the staff results with additional information.
Tested and it appears to be working
Tested and appears to work. This is super cool (particularly publish sort for DOs). Now if only dates and extents were not strings…
New test server available: http://searchprefs.lyrtech.org/