After all the hard work of cataloging you'll be happy to learn there are a number of ways we can exploit the effort to good end within the CMS:
- Direct inline reference to a catalog record
- Building Resource Lists
- Search/Browse interfaces
The simplest approach is just to put a reference to a cataloged resource within an existing CMS page. This is explained here in the CMS documentation. Essentially one inserts a tag containing the record's master id and the CMS automatically generates: a link to the cataloged site, a 'more 'info' link to a summary catalog record, and cross-references so that folks discovering the catalog record can find the page that referenced it.
By default the link to the resource is displayed as the title of resource. You can over-ride this by providing alternate text in the tag: [resource 123 'link text']. This will make a link to the resource with the words link text. Additionally one can ask the link tag to also display the short description of the record (which defaults to the long description if no short description is available). Just add the word description to the end of the tag. This can be combined with alternate link text like this [resource 123 'link text' description].
Descriptions short and longThe cataloging tools support two kinds of description: short description and the normal 'long' descriptions. The later is what the cataloger writes up when first creating the record and is covered in more detail here. Often however this description is too long for contexts like search results or a list of resources where having a brief (usually one-line) description is handier. To support this all catalog records have a 'short description' field where one can add a briefer description for these contexts. One also has the option of creating a short description for a record when adding the record to a resource list (see below).
This short description is tracked with the resource list rather than in the record itself. However, if the record in question doesn't already have it's own short description the resource list short description will be replicated into the record's short description field. Having short description in both places allows you to keep a 'generic' short description in the record itself that will be displayed in most situations, but also have a different short description in a particular list that has a different editorial slant (presumably something more in line with the context in which the lists will be used). Also, in all cases where short descriptions are displayed the system will revert to using the long description (which it will automatically shorten in circumstances where space is tight) when no short description is available.
By and large we'd like to replace links throughout our site with references to catalog records (at least in cases where the site is something worth cataloging). Often we end up making a site with alot of traditional links and then go back after the fact and replace them with references to the catalog record (so that the author isn't held up by the cataloging process). To that end we have several tools to automate the process. We can identify all the 'traditional' links in an area of the site and we can (after we think corresponding catalog records have been generated) automate the replacement of the traditional links with references to the completeed catalog records. This process requires a little setup by Sean and is something run (by hand) by SERC. So if you think you'll have a situation like this: you'll be cataloging a bunch of links already part of a site in the CMS; you'll want to coordinate with Sean to take advantage of the automated tools.
A step beyond single references to catalog records are resource lists. Building resource lists is described in the CMS documentation briefly. This is especially handy when you have a small (a dozen?) set of resource which you want to list out and provide some specialized descriptions for. In theory one could do the same thing with a list of single resource tags. The resource list just gives you a handy way to deal with a related set of resources.
The most powerful tool we have for displaying sets of resources is the faceted search tool. This allows folks to search across the text of resources (that which appears on the 'public view' page) as well as to browse a set of resources based on the controlled vocabulary terms assigned to them.
The actual definition of a particular browse interface (what records it will search, what vocabularies are available for browsing) it setup at SERC. The end result is a single tag with a unique number that identifies that particular search interface e.g. [browse 123].This tag can then be moved into an appropriate page and the corresponding search interface will appear.
From a cataloging perspective the most important consideration is that the browse feature relies on terms to be correctly checked within the controlled vocabularies relevant for the particular browse. As long as these are cataloged appropriately everything should just work.