As mentioned here, it has been decided (well, sort of) to pursue evaluation of Dspace as a content management system for the Landscape Chaange project.
Some issues and answers
- can Dspace do the job?
Yeah, probably — but this is what the evaluation is all about
- Why Dspace?
Any image repository/content managements system has three essential sub-systems: content ingestion, tagging and editing, deleting; searching; display. The current Landscape Change project has homegrown and buggy code for all three. Dspace has open-source community developed, tested, and maintained code for all three. By switching to Dspace, UVM only needs to re-develop and customize the object display sub-system.
- Will CIT continue to support Dspace?
Haven’t asked CIT management yet, but if we build it, they’ll come (around), I hope. CIT-TSG indicates we can have badger for as long as we want for development. Worry about final deployment later.
- What about disk space for Dspace?
For now, migrate 1/10 Landscape records to Dspace to set up a small development model. Later, CIT-TSG indicates that swapping LCP-owned disk space (300 GB) to a different server is not a problem.
- Dspace configuration issues:
I asked the dspace-tech list this question:
We’re considering migrating the landscape change project and its 10,000+ images to Dspace, and then seriously customizing the look, feel, operation, and adding a laundry list of new features. The rational is that by using stock Dspace features to manage and especially search the collection, our student intern programmers can concentrate on interface design, display, and kooky new features in the recently funded grant proposal wish list.So my question: do we want to somehow integrate this new collection and a spiffy new front end with our existing Dspace collections, building an even larger Institutional Repository? If not, then solution is trivial — install a separate Dspace instance on a separate server. But if so, then what? One Tomcat, different webapps? One Tomcat, multiple Virtual Servers? Two Tomcats, different ports?
Got back respons from Geneva Henry (Executive Director, Digital Library Initiative, Rice University)
My "vote" would be to keep it simple; one DSpace. The customized interface requirement is something we’re running into with all of our collections in our DSpace. There is, however, an DSpace component under development that will support customized interfaces for each collection/community. Actually, there **were** 3 projects doing this. After the DSpace users group meeting in July in Cambridge, they agreed to combine their efforts in a common architecture; that work is currently underway, making it a cocoon-based solution. My DSpace developer, Sid Byrd, is up at Texas A&M this week, working with Scott Phillips and others on their DSpace team to help move that development along since we at Rice really do need it. I believe their targeting December for a release; anything we can do to move-up that time line will be done.
I don’t know how large your group is, but we’re quite small here. Maintaining many DSpace’s would require more resources than we have. With the exception of development and test DSpace’s, we only run 1 production DSpace and I’d like to keep it that way. - Dublin Core issues
Before I can begin ingesting LCP data into Dspace, I need to map current LCP meta-data values into Dublin Core (like?) entities.
- Dspace version issues
Not really an issue with respect to this project, but something I’d like to get to before adding more data. We’re current running 1.3alpha1, current version is 1.3.1 (neither alpha nor beta). This version has native LDAP support, but a littlle custom code is needed to automatically add new LDAP authorized e-people into a UVM group so we can password-protect certain items. This, too, will probably necessitate https access to the server, and that requires a certificate. So right there, I see another 3-4 days of work.
