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 [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpDvbViphhrx.pgp
Description: PGP signature
_______________________________________________ Dspace-general mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/dspace-general
