It’s getting to be library instruction season, so this is probably something we’re all hearing right about now:
Sure, I’m interested in bringing my class to the library to work on their research paper. Maybe you can show them a couple of databases that might be related to their topics?
Ladies and gentlemen, I submit to you that the answer should be:
Well, okay, it’s more complicated than that. Here’s why:
Several months ago, Kevin wrote a great post about the psychology of learning. One principle he mentions is “deep structure.” Deep structure is basically the essential components of something that can be used to draw analogies to something else, despite surface level differences. It’s a principle that comes from linguistics, but has been adopted to describe the underlying meanings in many other fields as well, including education (it’s particularly caught on in math). Recognizing the deep structure of something is a complex skill, one that often requires expertise in a specific area. In one classic example, students were asked to sort physics problems. Beginning physics students put the problems into groups based on commonalities in the problem statement (for example, they would put all the inclined problems together), while those with more experience grouped the problems based on the skills they need to solve them (Bedard and Chi, 1993).
There’s another famous example of this that comes from the Bedard and Chi study and which is recounted by Willingham. Students are presented with two problems, one about therapeutic rays targeting a diseased organ, and one about armies attacking a castle. At first, the two problems seem completely unrelated; even if students could solve one problem, they often couldn’t solve the other. The trick, of course, is that the two problems require the same solution; it’s just hard to see that because of the narrative gloss on the problem. Once students are trained to look for the deep structure beneath the irrelevant details, they are able to much more quickly solve the problem.
I would extend this to library databases: Beneath the EBSCO, ProQuest, or you-name-it vendor facade, most databases work in similar ways. That’s why librarians don’t collapse with anxiety every time we encounter a new database; we understand the deep structure of what’s going on, and can take what we’ve learned about databases before and apply them to a new situation. (Yes, there are some databases that require particular training and are sui generis; I definitely acknowledge that things like PubMed exist and require instruction.)
In first-year writing and similar courses, it seems to me that it is of value to attempt to expose some of the ways that databases work with students, in an attempt to get them able to transfer that knowledge…in 75 minutes or less. Have we been set an impossible task? Perhaps.
Transfer, the literature tells us, is most likely to occur after continued exposure and practice with the knowledge in question. At the same time, in a given lesson, we can’t do too much and expose students to a laundry list of new material. So what if we taught deeper, and less? I think it might look like this:
Begin the class with something students are already familiar with—Kevin likes to use Google, and so do I. But you might also use another search engine, or even the library catalog, if your students have already encountered and used it before. Talk about what it’s indexing, and what it isn’t.
Then I would talk about how that search engine is different from a library database, and why that matters. I usually show a general database like Academic Search Premier, and we do side-by-side comparisons. We discuss facets and search string, and how that works. Then we’ll look at an item record and dissect what’s included, and how it turned up in our search. All this takes about 40 minutes.
Then, for the last 30 minutes of class, I direct students to our database list, and a) give them some suggestions of places to look based on their assignment or b) invite them to explore by discipline. We don’t talk about any of the databases explicitly other than the general one. I save a few minutes at the end of class for us to discuss the individual databases they used.
By talking about how a database works and explicitly stating that most databases work similarly, I try to strip away the surface differences and expose the deep structure. Then I ask students to apply that to a new context immediately. When I have taught multiple databases, I find that a) I repeat myself, b) people get bored and only use the database I talked about first or last, and c) no one explores any databases that we didn’t talk about. Exercises like this eliminate all three of those problems, as well as expose and demystify how databases work. Students do get exposure to multiple options at the end of class, but I don’t explicitly “teach” multiple databases.
How many databases feel right to you?