Note: This is a collaborative project with Doug Shuga, soon-to-be graduate of The University of Texas at Austin School of Information. You need to hire him.
This excellent article by William B. Lund and Chad Hansen at Brigham Young University demonstrates how one can embed subject-relevant research guides into search results. The beauty of this is the usage of third-party search algorithms and result sets to identify the broad subject area of a search, regardless of what the user types into the search box.
A user can type anything into a search box. Any word, any phrase, misspellings, colloquialisms. Because of the open-ended nature of the search box, it’s not easy to use search terms to do anything useful outside of re-running a search somewhere else. If a user types in “evolution and creationism”, I have no easy way of mapping those terms to our biology or religion subject guides. We can’t possibly map the infinite words users might type in.
Enter Mr. Lund and Mr. Hansen’s brilliant idea. Let a third party do the hard part by providing a search algorithm and relevant search results. Use the search results to figure out useful information about the search. Lund and Hansen used LibraryThing. I used Ebsco Discovery Service (EDS), but really, this could be done in any interface that produces search results with some form of call numbers.
This project is about placing subject-relevant research guides in a user’s search results in EDS.
A user types in some search terms and hits “Search.” Ebsco Discovery Service brings back relevant search results, many of which are books from our library’s catalog. In the search results screen, under each result that was pulled from our library catalog, you’ll see call numbers.
Before you begin to code, you first need to identify what subject-based research guides you have. Ignore any course-specific research guides, as there won’t be any way to tell from the search results if the student is researching for a particular course.
With a list of subject-based research guides, identify the call number ranges associated with those subjects using the Library of Congress call number ranges. You could do this with Dewey, in theory, too. This will identify which call number ranges you should be looking for in your search results. You may have gaps; for example, you may not have a research guide for Engineering if your school does not have an engineering program. This is fine – you only need to identify the call number ranges for which you have subject guides.
What results is an Array filled with the first portions of the call numbers on the page (e.g., “N”, “HV7332″, or “QH”). The next step is to map the call number prefix to specific subjects and tally how many hits we have from each subject area. We iterate through the entire array, matching each item with a predefined set of call number prefixes. If we have a match (e.g., “N” was in the array and we have identified “N” as Art and Art History), we increment a counter for the relevant subject area.
After counting up how many hits there were in our defined subject areas, we sort from highest to lowest, excluding all subjects that had no hits. We then display URLs associated with the subjects in an Ebsco Discovery Service widget on the right side of the results screen.
Here’s the code in .txt format. (You may need to right-click and do a ‘Save as…’ to see the code.)
In the code, you’ll notice a built-in delay of about 2 seconds. This gives EDS enough time to do the real-time availability check and display the call numbers before the script runs.
We hit a character limit with Ebsco Discovery Service’s widgets. The full code that included all of our subject guides exceeds the allotted 8000 characters. When trying to place the code on another server and using an iFrame to bring in the code, we found out that most modern browsers prohibit the kind of screen scraping we’re doing if the code doing the scraping is not on the same domain as the page being scraped. For now, we’ve asked for Ebsco to up the character limit so we can finalize this project.
This only works if the search results have books with call numbers, and will change from page to page of results depending on the results on that page. We tried to identify other sources of finite, subject-rich information on the page, but only subject headings provide that – and even then, there are too many subject headings from the variety of databases we have to make it worthwhile to attempt to map them to subject guides.
This is a bit more work intensive than other projects – if a new guide is produced, it will require identifying relevant call number ranges and adding code in three different places in the widget. Same if a guide is deleted. The work isn’t difficult, but there is maintenance to be done.
The links and what they do should probably be more obvious; we haven’t done any user testing to see if users notice them, or if they’d be useful.
Our Research Guides need to be standardized. I mentioned this in my Blackboard / Research Guides post, so this is just raising the urgency for improving our guides.