Slipping below the surface.
The process of identifying the “right” digital repository software to implement at my university continues apace, with the most recent efforts surrounding a specs-level evaluation of six or seven systems (DSpace, Fedora, and so on) to see if we could identify showstoppers from the very start (either technical capabilities we know we want, or features “incompatible with IT,” as on might say). The evaluation was successful, in the sense that we’ve managed to narrow our pool considerably based on design, licensing, or other factors. We’re now faced with a more daunting task: we not only have to review what we can see of these systems in the wild - which amounts to little more than the front page and, if we’re fortunate, the ability to see public collections - but also dig into the systems to see how they work on the inside, and how people use them.
So, the question on my mind is: how exactly do we do that? Test installations are a must. We need to see the system in action, develop sample content to deposit therein, and see how many different ways we end up breaking the repository (or just being incredibly frustrated with it).
However, the software-technical side of the repository system is less useful for most of us than an understanding of how repositories are used, and in fact, if they are used. From the literature and from presentations, discussions, and my reading about institutional repositories, it looks like that “if” is a much larger concern than the implementation of something cool.
Of course, the larger point is that, assuming a certain level of functionality, the software really doesn’t matter (if you ask some of the experts in the field, there aren’t any good ones, anyway). We need to use something that will provide sufficient function and be acceptable to our IT services group. On the other hand, contributors to the repository may have a general interest in what it can do, but they’re only going to be interested to the extent that it does what they want it to do - as with most things, users will employ a satisficing process to evaluate this resource the same as they will any resource.
So if we are to seek out how repositories are actually used, what do we do? To whom do we speak? We hope to speak to repository coordinators / directors at other institutions, but I’d like to get into the user’s mind too, and get beyond the “obvious” use cases.
To that end, I hope that the repository coordinators at other institutions will point me toward some frequent users, but if any of my few readers do have further suggestions along those lines, I am most interested in hearing them. I have few preconceptions about this process, so I am as a blank slate.