Searchable Collections, Vocabularies and Mini-Collections
The CMS offers a number of tools with which you can build searchable collections: collections of local web pages, collections of print resources and external websites, collections of files and images, collections organized around a particular topic, or representing the work of a particular group.
The Browse Tag
At the center of every searchable collection is a browse tag that looks like this [browse 123]. This tag (or one like it) will create a full-text search/browse interface at that point in the page. The trick is that the parameters of the browse: what it is searching through, and what options are available in the interface, need to pre-defined. Normally you work with SERC staff to define a browse that meets your needs. Then with the unique id number in hand you can put the browse tag into a page and get your search interface.
Some things to keep in mind with browse tags:
- It's best to keep browse pages as simple as possible. Usually just a title and the browse tag is sufficient. Perhaps a sentence or two setting context at the top if it's critical. If you put much more than that ahead of the browse tag then the search interface will become awkward to use as folks will have to scroll down past the text after each search to get to their results.
- Search interfaces on dev pages will only display results that are on dev page. As you might expect the same browse tag when appearing on a live page will search across only live pages. So you'll want to make sure the page with the browse tag goes live in a way that in accord with the material you're searching.
- Changes to pages that are being searched across won't be reflected immediately in the search interface. There is a roughly 15 minute delay between when you make changes to materials in the site (pages or records of print or internet resources) and when those changes show up in any of the search interfaces. The length of the delay will depend on where the system is in its update cycle. So it may be only a minute or it may be longer.
- Normally you want to include only a subset of all possible items in a given browse. The main ways you have to limit what shows up in a browse are:
- type of information: local web page, catalog record of print resource, catalog record of external website
- location of web page within SERC: only the pages in a particular module or modules.
- some combination of controlled vocabularies: e.g. all the pages that have (or have not) been tagged with a particular term in one of our controlled vocabularies.
Controlled VocabulariesThe most powerful tool for organizing materials in collections are controlled vocabularies. Each vocabulary is a hierarchy of terms which breaks some larger concept into a set of categories. Vocabularies span the range from tiny vocabularies with only a handful of terms which might be used to categorize a small collection, to comprehensive vocabularies (such as SERC disciplinary topical vocabulary) which include hundreds of term nested within several hierarchical layers. There is a public list of vocabularies currently in use at SERC; and new vocabularies can be quickly developed (or existing ones augmented) as appropriate for any project.
Individual terms from any vocabulary can be applied to any items in the CMS (web pages, catalog records, files and images). Once tagged the items can be included and excluded from browse interfaces based on these tags. By combining multiple such criteria one can construct browses that focus in on a specific sort of resource (e.g. only web pages marked with the vocabulary indicating they are activities AND which are marked as having to do with paleontology).
There are several core vocabularies (notably the disciplinary subject vocabulary and the resource type vocabulary) that are usually applied to most items in the CMS, allowing cross-project searches to be constructed. In many cases custom vocabularies are also developed to meet the special needs of a particular project. You'll want to talk with SERC staff about what vocabularies to use and if it's appropriate to develop new ones for your project.
Controlled Vocabularies also play a key role in browse interfaces. Often a browse interface will be defined to expose one or vocabularies as mechanism for browsing through the collection; complementing the full-text search. So often vocabularies will be constructed with this sort of use in mind.
Applying Controlled VocabulariesTo apply a particular controlled vocabulary term to a particular CMS page the first step is to make sure there is a vocabularies element associated with that page. Some page templates include a vocabularies field by default. If that's not the case you can add one using the Show Options for Adding New Fields option at the bottom of the full editing interface and choose the Add Controlled Vocabularies option.
- Select the vocabulary from the pull-down menu and click Make these Changes
- Click the Show me so I can change it link to reveal the list of terms in the vocabulary
- Check the box next to the term and click Make these Changes again.
Files, image and catalog records all have similar interfaces for adding controlled vocabularies term. Note that the CMS has a synonym system which allow some terms to be automatically selected based on other terms (e.g. if there are terms in two different vocabularies that are logically synonymous this can be used to make sure all the relevant terms get selected with a minimum of work). So be aware that terms may 'appear' in a given page unbidden. If a given term appears and doesn't seem to make sense let SERC staff know the details.
Often when setting up a new browse you'll want to limited it to a small collections of pages created explicitly for the browse. In this case the best approach is often to create a special kind of module called a mini-collection. Mini-collections are a type of module used to aggregate groups of independent (though uniform in structure) pages into a collection.
Mini-collections don't have a local menu since there isn't any particular logical flow amongst the pages to represent through a menu. Instead people find their way to a particular page within a mini-collection via a page with a browse tag. The left menu in a page that's part of a mini-collection is usually set (by default) to the local menu of the parent module (the same as the page with the browse tag).