Competency E – Retrieval Systems

Competency E – Retrieval Systems

Competency E: Design, query, and evaluate information retrieval systems.

Meaning and Importance

Though I have personal and practical experience with searching and using databases, I have not previously had much opportunity in actually MAKING a database. Information retrieval systems can be as simple as a telephone directory or as complicated as a website such as WorldCat, but the important part is that they’re usable and useful for the library patron (and library staff) in getting information to the user.

A well-designed system should allow its user to effectively search for needed information, taking into account measurements of relevancy, efficiency, and user-friendliness. If the system isn’t usable for whatever reason, whether bad design or incomplete information availability, then the library becomes less of a useful place for its patrons, and the library community suffers. Library professionals must be able to successfully evaluate the design and query of an information retrieval system and how it relates to their patrons.

An information retrieval system must be designed with the expected user in mind. Who will use this system, and what sort of features will they need? For instance, a typical user of a library catalog may need to be able to sort by title, author, and book location. The creator of that catalog then must take that into consideration when designer the user interface and the capabilities of the system itself. If the catalog doesn’t even have an author field, for instance, than it is NOT a usable system.
On the other hand, the system designer should not go overboard with complex database designs just because they have the capabilities of doing so. A typical public library patron probably does not need to search for books by publishing location, for instance, and so the IRS designer shouldn’t include that field option as it would lead to an unnecessary bloated system. Taking into consideration the needs of the user, and the information that is to be retrieved, should be at the forefront of all system designing.

A query in a database is a search: what is the user looking for within the IRS? Different IRS have different search structures—Google searches are structured differently than OPAC or academic databases searches, for instance. However, almost all searches have some corresponding features, so even if a user is only used to doing Google searches, they could most likely still get along with an academic database search for very general queries. A basic keyword search is the bare minimum of a database query, and these can be incorporated into using field codes for filtering out search results. Furthermore, Boolean search terms tend to be the same across all IRS, so users who know to use AND, NOT, and OR will be able to pull up more detailed search results.

Evaluating information retrieval systems means considering which database/search engine will do the best job, and why. Not every database system will work for every search instance, just like not every book catalog program will work for all library systems. Larger library systems with thousands upon thousands of books may need a more detailed catalog search than smaller systems with less materials.
Library professionals should evaluate not only what they themselves will need, but what their library patrons will need now and in the future. A smaller (cheaper) IRS may work for now, but if a library plans on increasing its holdings exponentially in the next five years, it may be prudent to invest in a more robust system that can grow with the collection. Furthermore, library staff should evaluate the IRS’ ability to search with precision and relevancy—if the catalog search can’t even conduct a basic Boolean query, is it really worth purchasing? Being able to test the potential IRS, and assessing whether it will meet the library community’s needs, is a key component of a library professional’s job.


INFO 202: Information Retrieval System Design
Link to INFO 202 Project 1

This class was one of the more difficult ones for me, as learning about systems and databases was so far outside of my realm of experience. Throughout my career at a public library, and even during my school journey, I’ve focused more on the public programs/reference side of things, as that’s where my interest lies. Taking INFO 202 in Fall 2015, where the final project involved building an information retrieval system, meant many new experiences that were completely outside of the realm of my knowledge.
Our first major project was to build a web-based database and write an essay about the experience. We separated into groups: my group decided to build a database for helping commuter bicyclists decide on a bicycle to purchase, using sortable information.

We started this final project by first narrowing down to our desired “typical user,” aka someone who is already somewhat familiar with bicycles but wants to be able to explore the different types available. This is somewhat similar to how a typical library patron would use a library catalog, for instance: most already have some idea of how to use it, and they want to search for a specific item. It allowed us to consider our end user’s needs, and how they would most likely need to query our database. Therefore, we were able to focus in one what kind of search operators and fields we needed to include in the database so it would be the most useful and usable for our users.

The technical aspects of the project were shared equally between group members. Each of us had to design a field, definition and rule for each aspect of commuter bicycles that we wanted to include in the database, and we had to make sure they all corresponded with what others in the group were doing. Then, we input these fields into the database program we were using at the time, WebData Pro. We tested the database we built over and over, trying to use it as an end user would, to work out any potential problems. We did have to tweak some rules and settings, which meant that we evaluated the system correctly.

I learned a lot from this project. Before, I had no real idea what went into building an information retrieval system, or why information professionals might want to use one IRS over another. Though I knew something about Boolean search queries, I didn’t know the reasoning behind them, or why they’re so important to have in an IRS. Now, I understand more about the process behind designing, querying, and evaluation information retrieval systems.

Future Application

Because I am mostly interested in programming and reference work, I’m unlikely to get much more experience in designed an actual database. However, I will no doubt have the opportunity to evaluate an IRS in the future, as libraries frequently upgrade and change their systems. In the future, I plan on using what I learned at SJSU to evaluate these system, considering the end users of them (whether library patrons or staff), and considering their search (query) capabilities within the confines of my users’ needs.

Follow Me