Research Guide goals

High level overview: What is a research guide?

For purposes of this project, a research guide is simply a document that happens to contain lists of resources interspersed among other (optional) explanation and text. So, a typical rendered guide might be:

The guide authoring application

The heart of a guide system isn't the guides themselves, but the authoring system used to produce them. Re-rendering good data into another format is relatively easy; making authoring easy, consistent, and error-free is not.

Guide authoring can be made easier through the use of specialized editors – simple editors that allow an author to add easily-accessible (and, when possible, universally-valid) information to specify a unique object. Many things in the library world – journals, books, and URLs and OpenURLs – are already globally unique. Others (subject categories, individual librarians) are locally unique. In all cases, any time we can provide (a) a special, easy-to-use editor and (b) an easily-localized way to render the data collected into the correct object, we've made things much easier on the author and removed the temptation to hand-enter a potentially-brittle URL or description.

Ideals for data storage in a guide

There are obvious things to which we should aspire, and others to avoid, when thinking about creating a guide authoring and
rendering application: avoid link-rot, make authoring easy, provide a way to push guide information into different formats, and (hopefully) provide a way to make guides reusable across space (institutions) and time (semesters).

To make up an acronym for no reason, I'm going to refer to the Minimum Necessary Information (MNI) needed to get all the useful information about a guide entry. For example, a book may need nothing more than an ISBN; the MNI for a journal is just an ISSN, and a subject specialist the name of the locally-defined subject she's responsible for. In many libraries, these would be sufficient to get titles and descriptions, create links to locally-available resources, produce OpenURLs when it makes sense, and create a targeted search box when possible.

1. The lowest-common denominator for an entry is simply a textual description. It cannot be (reliably) matched with a reasonably-identical entry in another guide, and hence will exist only for that guide. They are portable across guides and institutions in that they'll simply need to be checked for accuracy.
2. The next step up is the hand-crafted URL. This can be checked against the existing database of URLs, so that a single reference can be made and a change (if necessary) propagated out from only one place. They are portable across institutions, give-or-take the needs of proxying and authentication.
3. Next is the locally-defined UIDs. These could be usernames, local ids for databases, entries into a local text store, etc. These would certainly need to be re-crafted when moving across institutions, but allow for easy changes locally if, for example, the subject specialist for an area changes. These will require integration (at the UI and backend level) with institution-specific lists of resources such as other guides, subject specialists, database subscriptions, etc.
4. Finally are globally-valid IDs such as OpenURLs and the like (which can essentially be left untouched throughout the guide process) and ISBNs (which are valid everywhere but would need local customization to, e.g., fetch title information or create a link into the catalog).

MNI Form, Datafiles and Renderings

Again speaking ideally, we can imagine four states of a guide document.

1. The guide's "MNI Form," which has only the MNI for each piece of data and (of course) all the surrounding text
2. The "datafile," which may include fetched data (e.g., book title) but still has placeholders for, say, specific URLs.
3. An actual "rendering" of that datafile into XML, HTML, PDF, etc. with all the localized URLs and searchboxes in place.

The key to avoiding link rot and promoting use across installations is to keep things in the template file as long as possible and set up a series of services that must be provided locally to fill in the gaps. These might be simple (providing a template to turn an ISBN into a link into the local catalog) or complex (set up a web service to turn an LoC call number into a list of appropriate subject specialist librarians).

Data type that might be rendered using only MNI and local services

coming soon

Description reuse

In addition to the obvious reuse of data through MNI lookups, it would also be nice to be able to have "standard" descriptions of resources that could be edited (or wholly replaced) during authoring. This is less of a data problem than an interface problem, and might not be worth the effort.

A first pass

Our first effort might be a system that allows a user, working within a set Guide structure of headings and such, to add entries when they enter a URL, title and description. The system then notices whether or not the URL has been used before and merges with the existing entry if there's a match.