The Logical Operator

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.

Uncategorized digital repositories, needs assessment, satisficing, use case, user

Because my institution is somewhat of a “latecomer” to the institutional repository initiative, we have the advantage of seeing what has come before - unfortunately, much of what has come before seems to indicate that the “digital repository,” at least in its current forms (DSpace, Fedora, ePrints, and other dedicated “repository” software), simply doesn’t work.

Oh, it works in the sense that it allows individuals to upload materials to a centralized server and tag the contributions with metadata (allowing it to be searched and interrelated). But the problem - something discussed pretty much everywhere I see repositories discussed (there are many, many blogs talking about this topic: Caveat Lector, for instance; Peter Murray Rust’s blog; the Digital Curation Center) - is that these tools, despite their power, are simply extra work for the people who are supposed to feed them.

Digital repositories, ideally, are the place where university faculty, staff, and/or students can place their scholarly work so that others can find it and so the university can accumulate a large digital collection of the scholarly output of its employees. The catch is that these systems require additional work on the part of the faculty member to participate, and the consensus among those who have investigated such things seems to say that faculty researchers are willing to invest precisely zero additional work in contributing to a repository. The value proposition for the repository is simply not adequately made. The visible benefits of this outcome are many. The visible benefits of the investment are AWOL.

Recently, a couple blogs - Digital Curation’s negative-click repositories entry and Peter Murray Rust’s put it on the web discussion - addressed the fact that nobody wants to mess around with clumsy, user-surly, or work-added repository systems. The “negative-click repository” idea focuses more on the pure lack of interest in investing “clicks” in the process of contributing to a repository. Chris Rusbridge’s argument is the “negative-click” repository, a system that makes the process of getting material into the repository transparent (or nearly so) to the contributor. Read more…

Uncategorized digital repositories, dspace, negative-click, repositories, slideshare, web 2.0, workflow