We have a requirement to give better visibility to certain collections (by name or type) within our various branches, through some kind of limiter, filter, and/or exposed facet in our search page(s).
Going forward, we'd like to see this address the following directions: 1) Being able to better highlight, search, browse specific collections by collection name or type rather than by Org Unit. Many libraries have special collections that are part of a particular branch location or system, and these may be "gems" or have other special features that merit exposing them more visibly other than through the usual "general collection" type of search. 2) Exposing hooks for institutional repository goals that may overlap with functionality in 1) above [see also note 1 below]; and, 3) Addressing any other scenarios that would permit the business units we serve to better hook into "Our bibliographic stuff" vs. "Their bibliographic stuff" type scenarios (since we're using Evergreen for tracking many departmental publications). These may be both well defined or they may be "virtual" in the sense of being somewhat arbitrary in how we define "collection". In regards to 1) above, we have an Org Unit in the Library selector called "Earth Sciences" under which we have the specific branches. But some of these branches have specific collections that we want to expose in search / filtering. Further, some of the "collections" we want to expose may *span* multiple branches (say a specific type of map collection available at both "Ottawa" and "Calgary" branches). While many of the collections we would want to expose by name / label have hooks into existing MARC-based data (e.g. the "Map Collection" for which we could hook into MARC coding, etc.), some of the time the hooks are not sufficiently complete enough in the data for our sometimes precise, sometimes arbitrary way we want to define "Collections" for exposure in search / display [see note 2 below]. Or it may be a mish-mash combination of access points that would make it hard (??) to present to the user. E.g. a "super Search Filter" box that for any given value could combine both search by Item Type as well as Copy Location plus maybe something else to hook into a particular "collection" ). Here are the options we're looking at: Option 1: Use the library selector We're already using this option as you can see from this screencap: http://tinyurl.com/cq4g8q4. Under "Ottawa (555 Booth)" you can see certain sub-units exposed but these are not actually separate org-units, but rather sub-collections of the parent org unit shelved at the same branch location as the parent unit. So while you can use the Library Selector to highlight and give visibility at search, etc. to certain collections (that fall under a particular org unit), one disadvantage is that your sub-collections will come with some org unit policy baggage (which can be awkward if they are high circulation items). So the library selector is a nice way to highlight collections that belong to a specific location, but not an ideal way in that **it was not intended for this purpose** - we just find it convenient for certain use cases. Option 2: Use copy locations In our library, sub-collections typically map fairly well to copy locations. For example, our copy location = "omab" maps perfectly for an aboriginal collection of monographs we maintain (but we currently don't expose any filter for specifically searching against that collection -- yet). So if copy locations A + B, etc. can map nicely to "Collection X" we could use a customized drop-down, say in the advanced screen, to expose a limiter to filter search to "Collection X". So the labels in the drop down would highlight whatever collection name we want to assign, and the values passed to search are actually copy locations, etc. This appears to be nicely supported in Evergreen out of the box with some minor customization to the OPAC display. Growing disadvantage with this option is that while it will work well for print collections, it doesn't work well for our collections with digital components. The Copy Location = "Internet" is problematic and there is a growing use of bibs with no copies (e.g. E-books, etc. transcendent bibs, etc.). This would be where using copy location mappings to collection names would not be sufficient. And not all the collections we'd like to highlight with a filter or facet are copy location mappable... Option 3: Use custom 9xx field Use a custom 9xx field and expose via custom index, drop-down filters in the OPAC, and /or just expose via a facet. Although it's another field to maintain, this has the additional advantage of expandability for related requirements like our institutional hooks, etc., plus it can also be somewhat automated (e.g. Collections that map to copy locations and/or to MARC data can be auto-posted to any 9xx field through update scripts). A further possibility is to use combine 9xx use with the Authority Control Sets as per release in 2.2: http://www.esilibrary.com/esi/docs/?p=771 - but I haven't explored that yet. This looks like the best longer term bet. Other options: I'm curious if anybody else with these types of requirements have given it any thought or has comments on the above options. Thx, George Duimovich NRCan Library / Bibliothèque de RNCan Note 1: For example, if I wanted to pull out or expose all publications from **one particular sector** in our department, current bibliographic description doesn't provide any easy hooks for completeness in our search. It might be easier once our name authorities are improved re: organizational name changes, but some publications won't have predictable hooks because our scientist may not have been the primary author (e.g. that crazy rule of three practice), and so on. When in place, institutional hooks (say, our departmental org unit that published the material or the program under which that publication was created) will make it much easier to search and browse by those added access points. Note 2: For example, the "Map Collection" can already be filtered in the advanced search through "Item Type" (base upon MARC values) but suppose we had large map collection and wanted to highlight a **specific subset** of maps under a general "Collections" search filter, etc.
