[Dspace-general] Week 3: Good Repository Software

[Dorothea Salo]

On Fri, Sep 5, 2008 at 11:34 AM, Graham Triggs <graham at biomedcentral.com> wrote:

> That's a good question. You could also ask how long it would be the
> solution of choice if we simply chase other implementations?
>
> And I mean that in the sense of could we be leapfrogging other
> solutions, rather than simply following what they've done?

That's a question I can get behind!

> Dorothea, you can't simply go around uploading inflammatory material
> into your repositories to get the numbers up ;)

+1 -- and you owe me a Diet Coke and a new keyboard. :)

Roach Motel isn't the only item in MINDS at UW that's done those kinds of
numbers. I'd love to know what's inflammatory about an undergraduate
kinesiology journal -- I've been wondering!

> If they want these numbers in anything approaching a formal capacity, I
> think we both realise that we might as well just put a random number
> generator in there rather than bother trying to actually count anything!!

I got an excellent, excellent private email from Robert Roggenbuck
(which I strongly encourage him to post back to the list!) pointing
out that the serials world already has a standard called COUNTER that
addresses this question (see
<http://www.projectcounter.org/cop_books_ref.html#rbr_5> and
<http://www.projectcounter.org/cop_books_appendix_d.html>). I think as
much COUNTER compliance as we can claim (some of it, such as
independent audits, we can't) would be a big win, and an example for
other software and services.

> Or you could just use SVN ;)

Yeah, I can, but can my faculty?

 Having all of this inside your
> 'preservation' repository is rather sub-optimal - both for the purposes
> of the workspace, and for the long term sustainability of the repository.

Is it? I've been saying all along that a repository viewed as *useful*
is going to be a lot more sustainable!

> Maybe a neater solution would be a workspace / collaboration type
> service that enables all of the gathering of data and people working
> together, with the end result a SWORD submission to the final repository.

No argument. Show it to me such that John Q. Librarian can install and
manage it as simply as he currently does DSpace.

> Yes, it's a selling point of DSpace that it's a 'out-of-the-box'
> solution - but that doesn't mean it (or anyone's customised
> implementation of it) should incorporate every aspect of anything that
> touches on the content finding it's way into the repository.

It should if we want something other than empty repositories.

 The
> repository has a job to do, and there is nothing wrong - in fact, there
> is quite a lot of right - in having a suite of distinct, but integrated,
> services.

And there's quite a lot of wrong, too, in that institutions have
committed to DSpace, not such a suite. I can argue until I'm blue in
the face (and have done!) that they *ought* to have so committed, but
they didn't, and now we're stuck. The more I can make DSpace do along
those lines, then, the more wins I win, and the more leverage I have
to win still more wins.

Maybe the answer is finding another group of implementers to build and
document that suite. That would be a super-interesting project.
Likely? I dunno. I think I may get more mileage out of what I'm doing
now, honestly.

Here's another thing to think about. Resolved: it makes more sense to
build that suite on top of Fedora Commons than on top of DSpace.
Corollary: insofar as institutions decide they want such a suite (and
I definitely see motion in that direction from where I am), they will
abandon DSpace for Fedora.

> Now, can any one of the developers / committers unilaterally decide -
> actually, let's have the submission process look like this?

Probably not... but I'm giving my little all here to building enough
of a vocal userbase that the devs can make that decision and blame it
on us. :) Maybe I won't get there -- I know full well I haven't yet --
but we'll see.

> If there was a consensus as to what the sensible defaults should be,
> then there could be a commitment to delivering them in future release(s).

Putting on my Alan-Cooper-fan hat, I would say that
design-by-consensus piled atop some initial poor decisions landed us
in the usability mess we're currently in. I don't think more of the
same will haul us out, especially given the Ronco-Spray-On-Usability
approach we've taken heretofore. (See the brilliant and hilarious
<http://daringfireball.net/2004/04/spray_on_usability> for the origin
of that phrase.) I would be all for us throwing a real usability
expert (which I'm not; I just read a lot about it and understand the
low-level basics) at DSpace, and if the DSpace Foundation were to
canvass the membership, I wouldn't be surprised if an institution
containing such an expert proved willing to contribute his or her
services. (I know I'd be knocking on a few doors at MPOW.) Maybe for
2.0?

Dorothea

-- 
Dorothea Salo dsalo at library.wisc.edu
Digital Repository Librarian AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493