to search and, not necessarily, to find

It’s been a funny old day. I had a query from a customer today regarding a possible interface bug in our advance search. Most of my work these days seems to have degenerated to a mishmash of data entry, account maintenance and repetitive dull stuff. Yet, the job still has attractions. Today however, I had a proper librarian type question and thinking back it was something of a pleasure to discuss boolean searching, the need for brackets and search phrase construction. It was a reminder of one of the things I like about being a librarian, and that is being able to search, to have skills to search effectively, to seek information wherever it may hide, be it electronic, paper, fiche, film, or even papyrus (not that I’ve fielded one of those sorts of questions as yet). I don’t know if the librarian was satisfied with my response and there may well be an inconsistency in the search interface itself. As I commented, I have a sense that our search interfaces are designed more with the patron/student/customer in mind, than the librarian. Things a patron would forgive, probably not even notice, any good librarian would pick up. I don’t have a great deal of access these days to competitor products but one thing about my own company’s search that I like is that it still provides the ability to construct a full command line style search with nested boolean, etc.

Some of the skills required to construct a good search, or rather an effective search (one that returns primarily the results on topic with minimal superfluous material) are taught at the library school level. It seems that it is still the case, that some library schools are using DIALOG as a means to instruct in the construction of search strategies. When I got to library school, I’d come out of a comp sci degree (not to mention history and philosophy, ever the professional student was I), most of the tech stuff was easy, very easy, as was most of the search stuff, but DIALOG impressed me. DIALOG was serious searching, on the scale of some of the database programming I used to do in Oracle, nested searches, unix shell like options. It was a database that taught librarians how to do stuff compsci folk struggled with, and drove home the importance of good syntax, the need for being dogmatically clear about you asked for, not to mention a database constructed with the searcher in mind. Whereas these days, the database is mostly a collection of sources with a search box tacked on. In database vendor circles, they like to talk about the granularity of the database, the importance of the indexing, the metadata, where the information about the content can be as important as the content itself. For vendors, searching the data and retrieving useful results is very important and most recognise a need to support the needs of the serious searcher. So too, it’s often recognised that many searchers aren’t at home in the world of DIALOG and just want to find a few sources for that paper that’s due the next morning.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s