Creating the database category config file

Owned by Former user (Deleted)
Last updated: May 30, 2007Version comment
3 min read

Creating the category configuration file

Sakaibrary requires that each institution provide a configuration file that lists "categories" (in the form of quicksets and/or a multi-level hierarchy like High Level Browse) to specify how to organize searchable databases.

The rules are pretty simple:

  • Each category may contain databases, subcategories, or both
  • Databases may appear in more than one spot
  • Some subset of the databases in a category may be checked (searched) by default
  • There is one default category that will be selected when a new search form is visited

Options for presenting databases in Sakaibrary

We have at our disposal two pre-determined collections of database sets. First are the quicksets, which correspond almost exactly to the top level of High Level Browse (HLB) – the only difference is that there are separate Arts and Humanities quicksets, whereas "Arts & Humanities" is a single HLB top-level category. The other is the full HLB.

The option for presenting these default data that appealed to us the most is that it be based on HLB with the following characteristics:

  • Each top-level category will have two special subcategories: "All" which contains all databases in any of the subcats, and "Best Bets" which corresponds to the current quicksets.
  • The default search will be in "General Interest – Best Bets"
  • Each subcategory will have (at most) eight of the databases pre-selected for searching, in essence providing "best bets" at the subcategory level.
  • Any subcategory that doesn't have any searchable databases in it will be excluded.

What we can and cannot get out of Search Tools

The XServer provides us a way to build up the HLB hierarchy and get a list of the quicksets (which, for these purposes, are essentially categories with databases included but no subcategories).

What we cannot get out of Search Tools are:

  • a selection of the default category,
  • a specification of which databases should be selected by default in each listing (e.g., in each quickset or subcategory of HLB).
  • any sort of user- or site-specific sets, which we've always talked about but never really looked at implementing.

The idealized, long-term solution

So, we've got multiple sources of data (searchtools, librarian-picked pre-selected resources within the categories, and user- or site-specific sets which will in turn have their own pre-selected resources) that we need to merge into a configuration that can be read when a search is initiated by a particular user.

The idealized solution, to be pursued in the long term, is:

  1. Basic data be pulled out of SearchTools on a periodic basis (nightly? weekly?)
  2. We create an in-Sakai tool, the Site-Specific Sakaibrary Configuration (SSSC) tool, that can use the raw data pulled from SearchTools to specify which things are pre-selected and create new named categories/subcategories/quicksets.
  3. Instructors can use the SSSC to create special search sets for their courses; students can use it to create special search sets in their "My Workspace" area.
  4. When doing a search, the database sets that show up are those in any workspace (personal or course-related) the logged-in user currently has access to plus a special, librarian-run "Sakaibrary" space that will be used to specify the defaults. This way, even if you're in "My Workspace," you'll still see the defaults (from the Sakaibrary workspace) plus instructor-provided sets from your chem course and psych course and anything you've defined locally for yourself.

The problems with the idealized solution for the short term are:

  • It'll take too long to build
  • It presupposes that the configuration is read via some sort of database calls, which we don't do.
  • It assumes that someone will let us add a bunch of code to Sakai and still deploy it this Fall.

The short-term solution

The short-term solution we arrived at is as follows:

  1. Everyone uses the same configuration for their searches; there are no personal or site-specific search sets.
  2. The config file is based on raw data from SearchTools plus the simple addition of "what's checked by default" data from another source.
  3. The "other source" is just a CGI script on a library webserver, where we don't have to worry about folding stuff into the Sakai codebase and getting approval for that sort of thing.
  4. The combination is done by a simple script (again on the library web server), so all the Sakai servers have to do is pull a static file from a well-known location every night or week or whatever.

What we're talking about is simply displaying whatever hierarchy we decide upon with a bunch of empty checkboxes and allowing someone in the know to check the ones that should be searched by default (up to the maximum of eight).