[Dspace-general] Week 3: Good Repository Software

[Dorothea Salo]

> I'm going to bite on this one, as I want to ask a serious question -
> should usage reports play a part in encouraging deposits?

Well, in the sense of "they're a feature depositors both potential and
actual want/need," absolutely. I personally think it's incredibly
stupid that scholars are using SSRN download counts in
tenure-and-promotion packages -- BUT THEY ARE. That puts the
repository I run at a feature disadvantage. I also can't argue with
the (several!) people who have come to me asking for this. They want
it. I am their mouthpiece.

We also need to look at the repository-software market. EPrints does
this already. I'm pretty sure ContentDM and BePress do as well. How
long does DSpace remain the solution of choice if it doesn't?

Sure, a lot of counts are going to be low. That doesn't bother me.
Some won't be -- and just *one* case of "look! fifteen hundred
downloads in a month!" will make faculty heads pop up. (That's not an
unreasonable number; it's about what Roach Motel did.) Why would I
fight that?

> Would seeing low usage reports DIScourage people that would otherwise
> choose to submit? If you are looking at counts of accesses and
> downloads, how reliable can they ever be?

They can't -- but see all the ongoing arguments about journal impact
factors. Numbers are stupid, inaccurate, and deceptive. Granted. That
doesn't stop people wanting numbers, and not just any numbers, not
just whole-repository numbers, but THEIR numbers.

> If you are wanting to collaboratively edit a document, for example,
> would the better answer be to use Google Docs? *That* level of
> collaborative ability is way off the scope for what we could ever hope
> to put in to a repository.

Read the Google Chrome ToS lately?

No, we can't recreate Google Docs, but we might be able to do
something closer to SVN-for-documents. I could sell that... and then
I'd have access to preprints and postprints that I don't now.

 Rather, the question should be how can we
> better support external collaboration tools - ie. easy ingesting of a
> Google Doc into a repository.

Agree.

> I see that as being quite related to the above - as much of a users
> output should be captured [seamlessly] as part of their ongoing work.

That's the overarching theme I was trying to get at, yes. Thanks for
putting it so succinctly!

> I have sympathy for your plight. But I think (not necessarily in you, I
> hasten to add ;) that there may be some element of not accepting
> problems as political ones,

Oh, I know. But then our institutions start chasing their tails. "Why
hasn't the repository succeeded?" "Because it's under-resourced."
"What resources do you need?" "Well, a developer would help, because
the software is bare-bones and its developers won't address the needs
I have identified." "What? Why would we throw a developer at an
unsuccessful project?" and 'round the circle goes.

And that's in institutions *that have developers*. I'm sorry to
belabor this point, because I know I've said this before, but DSpace's
market position is "out-of-the-box solution," which means it's in use
at a lot of places with serious, serious resource constraints. If
you're saying they're plain old out of luck, okay, but I would want to
hear that said at a pretty high level before I'd be willing to shut up
about it.

>> - Bitstream-less items.
>
> that's already been done ;) (all developers down the pub then, right?)

Bleh. My bad!

> Although I'll make my obligatory statement about the need for this may
> be exaggerated - there are practises a repository can adopt for managing
> it's items that would alleviate a number of potential cases, and in
> relation to the points above about collaboration - there are better ways
> to address the problem *before* hitting the repository.

Maybe, but those ways tend to *bypass* the repository with the final
product. If we can address *that* problem -- and I agree that part of
it is non-technical -- I'm happy. If we can't, then I need something
to compete with other collaboration solutions, or I'm just written out
of the landscape.

> I agree with the sentiment. Lot's of issues to think about though in the
> wider scope - ie. how do you deal with updating the Terms of Service.

Definitely. I wouldn't be looking forward to going to Legal Services
to make this happen... but I would, because the reduction in deposit
annoyance, the vast expansion of material I could grab without
tediously negotiating with individual faculty every single time, the
destruction of the paper-based license workflow... it would be worth
it.

>> - Streamlining and simplification of the deposit process, including
>> accepting incomplete deposits (even just a file!) for later
>> inspection/revision/management by a third party.
>
> A lot of this could already be achieved solely through the configuration
> files - and maybe this could be aided by one or two 'non-interactive'
> submission steps being provided in the default DSpace, ready for
> configuring.

We're getting there, I agree... but we're a long way from sensible
defaults and sufficient flexibility still. Mediated deposit is a pain
in the posterior (especially as regards licensing), and it needs badly
not to be, because it's the standard case (not the edge!) in most
repositories.

> Isn't this about 90% outside of the scope of DSpace.

Building the individual pieces, yes, probably. But in my opinion it
needs to be easier to embed these gizmos in DSpace. This is partly a
communication problem, I think; we in the community simply don't
document what we do so that we can be emulated.

We may be talking about this next week, so I'll let it go for now,
noting only that one of the things on my Manakin to-do list is a
better thumbnail browser for image collections... and if I get
something halfway decent, yes, I'll throw it over the fence.

Dorothea

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