[Dspace-general] Week 3: Good Repository Software

[Mark H. Wood]

On Tue, Sep 02, 2008 at 10:27:39AM -0500, Dorothea Salo wrote:
> The problem that DSpace was designed for -- self-archiving of
> peer-reviewed journal articles in an institution-based repository for
> purposes of open access -- does not appear on the above list. Bluntly,
> this is because faculty do not perceive self-archiving as a problem
> they have or wish to solve.

Nor should they.  This is in large part a political problem precisely
because the people who want an IR and the people who fill it are
disjoint sets.  It's the institution that (sometimes) perceives value
in an IR.  If the institution makes non-contribution a problem for
faculty then faculty will want a solution.  Perhaps not a happy
situation.  I'd like to hear of better ways.

Faculty who want anything other than the status quo probably want
disciplinary repositories, as has been pointed out before.  The scope
of the individual repository is probably irrelevant to the design of
the tool, at least within the academic sphere.  (The scope of the
content surely is relevant, but that is another matter.)

There's no reason that policies cannot permit, and encourage, deposit
in both kinds of repositories as well as commercial publication.  They
just don't.  Policy isn't properly part of the tool unless the tool's
purpose is to enforce policy.

Is there something special about IRs as opposed to any other kind of
Rs which requires us to choose a path when designing the support tools?

> - True dark archiving: fix the OAI-PMH hole, please! Some collection
> owners do not *want* or *cannot legally leave* collection metadata
> hanging in the breeze. They need to have the option of hiding it
> *completely*, or they walk away from the repository.

If DSpace is going to represent access permissions, then the access
model should extend throughout the product.  The PMH server should
respect the access model.  This still allows a site to set anonymous
read access on all objects if it choose.

> - Embargoes.

A proper part of the document data model IMHO.  It's been done, but we
need it incorporated and configured on/off rather than patched in.

> - Elimination of per-item licensing, replaced with a single Terms of
> Service click-through. (I can elaborate on this if desired.)

We've done that here in specialized circumstances.  The hack is that
every registered user of one of our DSpaces is automagically made a
member of the depositors group of the single collection in that
repo. and the registration form extended to require acceptance of the
deposit license at registration time.  It could be done better.
 
> - Better display options for a broader variety of content. I need a
> page-turner, an image browser, and a journal browser that behaves like
> a journal browser -- and that's just for the content I *currently
> have*, not the content I foresee wanting to cope with in future.

Those are tools which address more than just DSpace.  Can we find a
way to separate them from the repo. across a well-defined interface
which can be used by other services too?
 
> - Easier machine-to-machine deposit. SWORD is good, but frankly, it's
> too hard or out-of-reach for most of the data sources I can imagine. I
> need DSpace to deal with crappy RSS feeds, because crappy RSS feeds
> are what by-author searches of literature databases can produce, and
> local IT folks can usually hack together crappy RSS feeds. I also need
> DSpace to cope with watch folders, because "put it here on the server
> and I'll deal with it" is a value proposition I can sell. So is
> "DSpace will watch your page and ingest any new issues of your
> publication automagically." So is "DSpace can serve as the
> preservation datastore for your
> OJS/OCS/Omeka/ContentDM/Greenstone/Kete/whatever installation."

I think that SWORD or something like it is exactly what you need, but
you shouldn't have to deal with it directly.  DSpace won't solve this
problem, but the DSpace community can!  Those who can build tools to
do this, please share them; those who cannot, please share ideas.
It's likely that one site's solution will be useful at other sites,
though not all.  A collection of several solutions, available to the
community, should serve most needs.
 
> - Better hooks for transcluding metadata in other contexts. I want
> one- or no-click publication histories by author, in HTML and RTF at a
> minimum. I want prettily-formatted, logically-organized lists of
> publications in a given collection via a single line of Javascript. I
> want Researcher Pages. (One of the campuses I serve is seriously
> threatening to defect to BePress because of the Selected Works
> feature. This is what I mean when I say that value propositions for
> depositors are *not optional*, *not frills*, in DSpace.) I want COinS
> and RefWorks export.

How do authors manage their records of their own work?  Would they
prefer Yet Another List, or a way to suck the information out into a
mechanical bibliography compiler of some sort?

Thinking of our own contributors:  we run several DSpaces, ContentDM,
OJS, and we're tooling up our second attempt at a "blog hotel".  And
authors also still deal with dead-tree publishers, which relationship
is out of our hands.  How do they acquire and collate all of that
information? how would they *like* to do it?

I think that helping DSpace users become more a community and less an
audience will help a lot in addressing these "non-optional peripheral"
issues, which typically need a basket of solutions in differing styles
in order to please everybody.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/74a8701a/attachment.bin