On Nov 13, 2007 1:23 PM, Susan Teague Rector <[EMAIL PROTECTED]> wrote:
> Our debate here is centered on future support of ETDs in DSpace. We've > had to do quite a bit of customization to support ETDs (thank goodness > for Tim Donahue's code :)! Does anyone know if there are future plans to > better support ETDs in DSpace? With the understanding that I'm not a DSpace committer and not involved in any way with DSpace or the DSpace Foundation except as DSpace user and occasional bug or patch submitter... My sense is that DSpace development has only vaguely and loosely been guided by real-world use cases not arising from its inner circle of contributing institutions. E.g., repeated emails to the tech and dev lists concerning metadata-only deposits (the use case there generally being institutional-bibliography development), ETD management, true dark archiving, etc. etc. have not been answered by development initiatives, or often by anything but "why would you even want that?" incomprehension or "just hack it in like everybody else!" condescension. There are hacks for some of these uses, yes... but from a sysadmin's perspective, hacks endanger smooth upgrade paths, and from the perspective of many librarians, hacks are entirely out of reach because IT rather than the librarian controls the box DSpace lives on. When innovation has occurred around DSpace, it has generally died on the vine because of the aforementioned threat to smooth upgrade paths. TAPIR and Researcher Pages may serve as the requisite gruesome warnings here; they died not because the ideas underlying them were bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't have had to ask the question she just did!), but because almost nobody dared adopt them. I see all kinds of nifty conference presentations involving DSpace mods -- but they provide me no practical benefit whatsoever, because the code isn't out there and I probably couldn't use it if it were! DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti dinner under its hood, has stifled service innovation in the repository space for years, and will continue to do so until the defect is rectified. Neither EPrints nor Fedora is in a much better position just now, but in all honesty, I predict that the first platform to *have* a half-decent mod API (especially one that welcomes mods written in friendlier languages than Java) will experience an explosion of innovations that will eat the other platforms' lunch. Manakin assuredly helps, but not quite enough. SWORD may also help, rather backhandedly, by providing an ingest path that doesn't rely on the horrendous web UI or the awkward batch ingester. We'll see; I'm hopeful. I'd far rather build an ETD app that used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs myself, much less try to push the committer group to do so. It may be worth noting at this point that I put my votes where my mouth is; when the DSpace development survey came out, I put a mod API at the very top of my desiderata. I encourage other repository managers with unmet needs to speak up for this! It's vastly more important for the long-term health of DSpace and the services we are building around it than are (for example) controlled vocabularies. Dorothea -- Dorothea Salo [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
