[Dspace-general] Week 3: Good Repository Software

Graham Triggs graham at biomedcentral.com
Mon Sep 8 10:51:10 EDT 2008


Dorothea Salo wrote:
> +1 -- and you owe me a Diet Coke and a new keyboard. :)

remind me at the next conference we're both at!

> 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.

COUNTER compliance would be better than nothing.

>> Or you could just use SVN ;)
> 
> Yeah, I can, but can my faculty?

I didn't say directly! Just think how many people have been developing 
SVN, and for how long. If there is a need for versioning that goes 
beyond the most basic of requirements - as would be the case for some 
kind of collaborative environment - then there is so much more mileage 
(and efficiency) in building that part of the solution around something 
that already does it. Especially as you probably wouldn't be looking to 
capture and preserve the frequent minor revisions for the long term.

>  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!

Political vs technical argument, and you have to have a balance of both. 
  You may have the most useful and used repository in the world, but 
there is still going to be a limit which if the cost of technical 
sustainability exceeds, the plug will be pulled.

You are right in saying that DSpace does not adequately fulfil either 
criteria (then again, neither does anyone else or we wouldn't all still 
be doing this). But we do have to ensure that the technical side stays 
within bounds whilst improving it's political sustainability.

>> 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.

Funny you should say that, because it just so happens... that I can't. 
But that's not a problem, it's an opportunity ;)

> 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.

That's essentially where I'm pointing. Everybody has to deal with having 
limited sets of resources - the EPrints and Fedora communities are no 
different in that regard... we can't solve all the world's problems and 
have it done in time for dinner!

Not only are some of these pre-ingest [collaboration?] services distinct 
enough from the main function of the repository that they can and should 
be implemented as a separate service (*).

As a separate application, not only do you have three times the number 
of interested parties, three times the number of potential resources, 
you can also put together a funding bid. A collaboration service that 
enables researchers to work together across multiple locations, and 
collates their output for submission to a repository via SWORD (using 
SWAP profile) might be of interest to JISC for example - certainly more 
so than a similar project that extends DSpace internally and is 
therefore only applicable to that one platform.

(* and when I say that, remember that out-of-the-box things like 
OAI-PMH, SWORD and LNI are delivered as separate applications in DSpace 
- which could even be installed on distinctly separate machines, etc. 
even though nobody would know that from outside)

> 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.

If you need to do 'deep' integration with the repository, then Fedora is 
in a better place to build from. For what would effectively be a 
pre-ingest service, then you possibly don't need anything more for 
integration than SWORD.

Of course, a suite means having administration and dissemination of the 
repository contents, something that DSpace provides for less work.

You may be right that some people will abandon DSpace for Fedora if/when 
they realise they've made some incorrect assumptions about DSpace. I 
don't see that as problem though. We aren't trying to crush Fedora or 
EPrints, we just want to provide a good solution that serves a need.

> 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?

I'm not saying design-by-consensus - but there has to be a design, and 
there has to be a consensus that supports it. Developers randomly 
changing the interface in any number of different ways every release 
until we hit on something that people like isn't going to do anyone much 
of a service!

G

This email has been scanned by Postini.
For more information please visit http://www.postini.com




More information about the Dspace-general mailing list