So there’s two basic sorts of search you can be doing. You can be looking for a known item, or you can be looking to learn more about some topic. (And, of course, your handle on these things can be more or less fuzzy.)

The post’s contention is that library catalogs, architecturally, do a lot better with the first kind than the second. (I know some of my readers have had issues with known item searching in their friendly local library catalog. I’m talking about the idea behind the architecture here, not the quality of implementation.) Yes, there are subject headings and other conceptually oriented metadata in MARC, and yes, that stuff is searchable, but it’s not conceptually treated as the center of attention: “These concepts are represented in our MARC records, but as distinctly second-class entities. They’re typically attributes of the records that are the focus of the catalog, rather than focused records in their own right.”

In other words, the catalog is about the items, not about the ideas, and the post author thinks that’s a problem.

Interesting, interesting. Dovetails with a lot of the stuff we were talking about in my library software class last term about ILSes being set up to serve librarian workflow, with the patron-accessible bits sort of as an afterthought and, until recently, grafted onto an architecture designed around librarian needs, not built ground-up around an idea of patron interests or behavior. (That all is starting to change, and precisely in what direction is under active debate — see AquaBrowser and SOPAC and VuFind and the entireopen sourcemovement and my husband’s shiny new employer, although library stuff isn’t at all the focus of what they do…)

I also appreciate that the post ties in with the idea of search-as-iteration, not search-as-thing — I’ve encountered the latter too many times in library school, and it seems like the wrong paradigm to me. (For example, it doesn’t make sense to me to evaluate the success of a search by saying “I typed X, and the results I got represented y% of the applicable collection and contained z% red herrings.” Really? It seems to me success should be measured with whether you found what you needed at the end of your search process, but that process may have included multiple searches and refinements (and the ability to suggest helpful refinements is something by which both catalog interfaces and librarians ought to be measured). In some contexts that process ends after one search; in some contexts it doesn’t. Hey, look, a digression!)

7 January 2010

So my husband (a software engineer) and I talk a lot about this library stuff, duh, and it’s useful for exposing underlying assumptions that differ between these two fields of information geekery…

One of the things I’ve been thinking about is the structure of open source development communities. I’ve run Linux (albeit no more) and a lot of my friends are the kinds of codemonkeys who will merrily write a script when the world doesn’t do something they want it to do. I’m used to thinking of open-source development as people encountering things that are personally bothersome and fixing those themselves, when the software in question is something computer geeks use — Linux, Apache, funky lightweight apps to do whatever, et cetera.

But the assumptions in my head about how Koha and Evergreen and OPALS are developed are, I realize, different. I think of integrated library system development and I think of a small number of coders — from library consortia, academe, and ILS support companies — contributing to the codebase; I think of the vast majority of (potential) users as simply not having the ability to do that. In other words, I think of there being some latency and information loss in the communication between user and developer in a way there’s not with, say, Linux (where user and developer are the same person). In fact I imagine it must go both ways — that developers are not necessarily embedded in a library context (e.g. if they work for support companies) and therefore may not be heavy users of the system, and may not be developing that sort of intuition for the workflow imposed by the system.

Am I right? Am I wrong? Because I really have no idea, and it’s fun to use the blog as a way to learn things. (Thank you to all my lovely commenters who have pitched in on this. 🙂

It seems to me the nature of an open source development community, and the possibilities for the software, must be interestingly different depending on how greatly the user and developer communities overlap, but I do not really know how (aside from the suddenly crucially central role of support companies in the low-overlap case). Certainly, though, the idea that if software is broken or stupid you cannot just write something to fix it is a paradigm shift for software engineers, but not for librarians, which does complicate some of these conversations.