More on Repositories
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.
It’s a laudable goal, but I’m not sure how one would, in practice, implement such a thing, since even the most transparent approach has a direct impact on workflow (the exact thing that most potential contributors appear not to want to mess with - they don’t want to change the way they work). The challenge is to create something that:
- Integrates with any workflow
- Involves no (or essentially no) extra activities on the part of the scholar
- Uses the data structure of the material to create the interrelations critical to really opening access
- Provides a visible and obvious value-add that can be explained without looking under the hood
- Is not just a wrapper on some existing tool
Interestingly, Rust’s blog entry hits on something Rusbridge suggests as a possible solution: the use of multiple, simple tools that talk to each other and form an emergent product, rather than a monolithic “repository software” package.
Here at IUP, we’re attempting to frame the repository’s mission as supporting the entire process of scholarly creation - a “scholarly workbench” approach - rather than simply as a glorified file server. I think that a set of modular tools - like Rusbridge and Rust propose, combining the best features of tools like SlideShare, blogging, wikis, etc. - could provide exactly that. Right now, scholars are using online tools to create, collaborate, and share their work - if that sort of experience can be reproduced (or perhaps “formalized” is a better term) in a way that layers transparently on top of a person’s existing work process it could be a powerful way to enhance participation in and attention to digital repositories.
What would such a system encompass? What would it need to provide? The answers are pretty much the same as any monolithic repository product:
Storage: the system (or aggregate) would need to store copies of the relevant digital object in such a way that it could be reliably retrieved by any user. Most any system - Writeboard, SlideShare, even wiki software have this capability.
Interoperation: the system would need to allow other systems to locate said material by hooks into the system. Many W2.0 applications allow access directly to their content via syndication.
Metadata: tagging is nearly universal across W2.0 applications - it’s how people find things, the classic “tag-based folksonomy” approach.
Sharing: again, this is the entire point of most W2.0 applications. It’s not fun if you can’t share stuff. Community is the goal of most of the common web applications.
Ease of use: typically, Web 2.0 applications are designed to get you up and running quickly. You do very little to establish your account, and there are no complex permissions or technical fiddling to be done.
Rust points out that he finds the tools are best when focused on one specific type of thing. SlideShare (the example he uses) is for slides. That’s what it’s best at. It maintains a focus. So, if one could create a mechanism by which information feeds bidirectionally between the various Web 2.0 tools*, a “modular repository framework” might look like:
- Blogger/Tumblr for blogging and informal discussion, plus
- Google Documents for collaborative authoring and storage, plus
- Muxtape/Flickr/SlideShare for audio, images, and slide sharing, plus
- Digg/StumbleUpon for tagging and interrelating digital objects, plus
- SVN / CVS for version control, plus
- Bloglines for automated updating and alerts regarding objects of interest
I’m sure I’ve missed a few cool tools. I also realize that the above may be possible, although I am not sure how one might feed data one-to-the-next in an automated fashion, which would be the ultimate goal. In other words, if I create, for example, a slide show and put it in SlideShare, I would want its data structure and content to automatically create tags and other metadata, and that information distributed (again, automatically) to the other components without intervention on my part. I want to create a thing, and have the thing drive the rest of the process.
Thoughts, comments, criticisms, outright dismissals?
Hi Chris
I appreciate the “modular” approach wasn’t your idea per se and I have also been reading around some of the other blogs but your explication switched on a little light-bulb in my head; possibly just a late Friday afternoon phenomenon!
I’m glad it clicked! I just wanted to make sure I didn’t tromp any toes out there. We all help each other climb higher, after all.
-Chris
I pretty much agree with your approach, including the desire to build a scholarly workbench application, but in my own reply to Chris R’s ‘Negative click’ post I wanted to make the point that there are some workflows that are not going to work.
You say:
# Integrates with any workflow
# Involves no (or essentially no) extra activities on the part of the scholar
I think this needs to be looked at in a broader context. Some workflows are not worth encouraging eg if you had people who wanted to type things on paper then have it entered into a word processor then you’d go and help them. A lot of researchers are using their word processors as typewriters and in the process throwing away of lot of stuff they could capture as they write, like document structure, or labels on diagrams.
There’s no reason that users can’t do new stuff - it just has to be worth it, and displace some of the old stuff they used to do. If all we’re going to do is tie into workflows that should be changing anyway then we may as well give up.
Peter, thanks for commenting. I totally agree - I was looking it from the “holy grail” viewpoint, where anything we create as scholars could be automagically sucked into the repository just because we wanted it to happen. Of course, practically, there’s a) no system that will be completely transparent, b) no such system, and c) no reason to encourage outmoded (or inefficient) workflows.
I think the trick is convincing people the workflow should change! But if there’s real value in the new workflow we present, then I think that trick is a little easier to pull off. Your point is well taken.