Tuesday, February 19, 2008

A new approach to web resource discovery

At JCU we've had static lists of subject-based web resources since the dawn of 'before my time'. This approach evolved directly from the 'Pathfinder' model I first saw as an undergrad circa 1989. A paper list of in-building (mostly) paper resources.

Now we have a electronic list of electronic resources with almost standard groupings like 'Databases', 'Ejournals', 'Associations & Organisations', 'General', 'Specific' etc. Over the years individual guides have mutated from the original template based on the nature of the subject and the preferences of the author.

These tools provide a menu of resources for the 'diner' to peruse over a leisurely lunch, rather than providing a drive through window for the student in a hurry. The choice to browse rather than search is often a product of need and time.

Browsing aids indepth knowledge (and often requires it).

Searching often satisfies an immediate need and requires less subject knowledge (particularly in assignments with set topics).

Can we provide one tool to support both needs?

The database section subject guides can also be an administrative burden. Many cite the same cross disciplinary databases, so when a name or IP address changes the edit has to be replicated in multiple files. Currently we store this information at least two other places:

  1. The catalogue, which in turn generates the static A-Z listing on the web site
  2. In X Search (the JCU implementation of Ex Libris' Metalib).
Conceivably it should also be stored in our ERM as well, although I'm told it currently isn't. It seems obvious that reducing data maintenance by having a central store and 'pulling' a list of relevant databases out of it dynamically and embedding them in the resource guide is preferable to maintaining multiple lists. And why not embed a search form in the subject guide that used federated searching to search those databases?

And if you are happy with that model can we transfer it to the other eresources currently listed in the resource guide pages? Could we create or use an existing database to manage/store web sites and draw on them to populate resource listings?

Well of course we could. To see how it might look take a look at the PHP/MySQL application
PirateSource developed by the Joyner Library at East Carolina University, also used by Curtin University of Technology.

What's missing from PirateSource is the ability to search the resources listed as a job lot. Which leads me to the next bit of this spiel: Google Custom Search. With GCS you can tell google exactly which sites you want hits returned from, in effect an expansion of using Google to search one site using the 'site:xxxx.edu.au' restriction.

As an experiment I've created a GCS that restricts to the websites listed on our Accounting & Finance Guide (does not include the databases, ejournals or ebooks listed, only the web sites in the last four categories),
take it for a spin. The results can also be 'iframed' inside an institutional page - which I haven't done at the time of writing, but may have done by the time of reading.

Of course we are then back to maintaining separate lists of web resources, aren't we? Not necessarily. If we could store all those web sites in ERM, with enough metadata to retrieve them, and if the Serials Solutions API is up to it, we could have one central database of resources that could populate subject guides dynamically with appropriate resources, and we could even have an option to search the retrieved resources simultaneously.

Except searching databases, ejournals and ebooks would be one federated search and all other web resources would be another federated search (Google Custom Search). The multitude of subject specific GCSs would have to maintained semi manually - a cut and paste from of the selectedURLs (one to a line) into the GCS 'Sites to search' box.

I propose all this as a talking point sparked by Helen Hooper showing me Curtin's subject guides. If you are interested in learning more please let me know.

No comments: