Almost 20 years ago I got my master’s degree in library science. At the time, I’d thought it likely I would go on to get a PhD within a decade. Things rather interrupted that. Still, I’d actually done some prep work on my dissertation project.
I dug out my notes recently, and discovered it’s still probably valid. I say probably as there’s some degree of “where’s the scholarship” and the inevitable need to link in other scholarly works (and the classes for the particular program). Nonetheless… I’m rambling. Sorry.
I thought I’d dump some of it here. I think, with the help of a programmer to polish, it would be a potentially usable (read money-making) tool. It is a graphic oriented OPAC.
First: OPAC. Online Public Access Catalog. What you get when you go to the libraries these days to see what books are available on a subject. Most of these are now available through the internet – link to your local library and you’ll see it in action. Now what makes my project particularly useful is that I think it can tie to existing search engines – google, yahoo, etc. Still, it begins as a catalog access system.
Let me begin by presenting it from the view of you the user. You enter a search term. You see what appears to be an unweighted tag cloud plus a few buttons. (Unweighted – all the text is the same size instead of sized by frequency of occurrence.) You click a term that is relevant to your search. It gets added to your search string and some of the words of the cloud go away. Three or four more of these and you like (or more likely don’t know whether they’re useful or not) the remaining terms so you click “show” and get a list of all the items for which this search applies.
I mentioned the “show” button. You’ve also got a “Did you mean?” button. This is going to bring up two new groupings of terms. The first group is (with more polite labeling) “User Error” options. These are terms which are very close in spelling to the originally entered term(s). That’s pretty obvious and needs no further explanation at this time.
The other button is what in the library is a “See also” button. Terms that are related to the original which are not showing up in the original cloud. Thus you may have typed “kings of England”, and see also shows you “Royalty of England” and other similar terms.
Now let’s go to background.
Originally, Card Catalogs were designed for the professionals, and are made to work for general users. Today, online search engines (and I include OPACs) are designed for general users and are made to work for the professionals. As a librarian I get frustrated at many things when using any search engine due to the lack of several historical tools that could easily be incorporated. Further I know from time on the reference desk that users are frustrated as well – if not ignorant.
I am certain that a well-designed search engine should work in a fashion similar to the reference interview. That is, it should help the user narrow their search from a very broad (and possibly slightly off) target to the more specific item(s) needed to satisfy their information requirements. However, most people aren’t going to spend several minutes typing in new words, especially when they have no clue what other words might be needed. (Further they aren’t looking at LCSH or authority files or any other professional tools; especially when they don’t know about them.) They also aren’t going to want to run through a questionnaire, not most of the time. It takes a well-designed AI or a human with some training and skill to know how much to ask (if at all) to help narrow the search.
However, I believe (and would test as part of the scholarship element) that a graphic demonstration of possibles could be used as an effective alternative to the reference interview and would be used and useful to patrons to help them find exactly what they’re seeking.
The words that appeared as choices would be from both professional cataloging (and so in accordance with standards to include Subject Headings guides, DDC terms, and authority files) AND from user tags. The user tags’ incorporation would create a functional authority file if anytime it were chosen the “see also” collection would be cued with all subjects and other marc elements to which that tag was applied.
The basic search would be a default boolean AND function. I would incorporate several advanced tools as well with the intent of keeping as much graphical as possible. For example, I would like to have options off a right click: “OR, AND, or NOT” being obvious. I’d like to be able to group (parenthetical inclusion) items using ctrl-click and shift-click as well as highlighting and choosing from a button. Highlight in the string would also allow “string” grouping (enclosing in quotation marks to indicate literal string).
Underlying this all is the fact that books are inevitably badly grouped on library shelves. It’s worth noting that this really only become evident as we moved to open shelves and larger libraries. For those who don’t get it, let’s assume you’re looking for information about Ireland. Now the odds are you’re going to see quite a bit in the 914s (I use Dewey mostly, LC users can get the idea) with some more in the 936s. That’s travel guides and historical Ireland, respectively. But you can also find Ireland discussed in the 790s (dancing and golf for example). In the 300s you’ll find discussion of the IRA. 740s for clothes, 800s for Irish literature (both Irish authors and literature about Ireland). Ireland’s contribution to religion may well wind up in the 200s. You getting the idea here? Yeah, thought so.
The purpose of the catalog is to help you find the items on the shelf relevant to your needs, wherever they may be placed. That placement includes not only modern open-shelf designs for serendipitous filings but older closed shelf techniques that include alphabetical (by title as well as by author), date of publication or purchase, size and color, and so forth. (No, I’m not kidding about any of these. They’ve been used and used effectively, and all have their advantages as well as disadvantages.) That’s the intent of this graphical system.
The PhD development would be two parts. One part is scholarship to demonstrate the effectiveness of this system. One part is the development of the system itself. The former is, from the PhD point of view, more important. It would require development of several effective tests to measure user usefulness, both perceived and actual, and include application of the tests to existing systems so as to establish a baseline before testing the new system for comparative purposes. Then the system needs developed – and needs to be pretty enough that it doesn’t turn off users due to the ‘student project’ appearance. Finally its use needs tested to confirm whether it does what it’s projected to do — be more effective at helping users find what they’re seeking.
Adjunctive elements could include a standard weighted tag cloud of previous user searches as part of the opening screen, saved searches, split searches (search this with and this without this/these terms, show difference). All of these can be directly applied to existing search engines on the internet as well.
My coding skills are more than 15 years old and weren’t “hire me” level at the time. If I entered a PhD program today one of the absolutely necessary supplemental courses I’d need would be updating my skills to something appropriate for this — though I do think my algorithm skills are sufficient to get a ‘real’ programmer to produce what I’m designing.
If you see me mention My (Graphic) OPAC, you now know of what I’m speaking.