Telling DSpace Stories at University of Konstanz with Stefan Hohenadel

Wed, 2015-09-23 08:59 -- carol

“Telling DSpace Stories” is a community-led initiative aimed at introducing project leaders and their ideas to one another while providing details about DSpace implementations for the community and beyond. The following interview includes personal observations that may not represent the opinions and views of the University of Konstanz or the DSpace Project.

Michele Mennielli from the Italian University Consortium Cineca interviewed Stefan Hohenadel, Software Development Team Coordinator in the Content-based Services Department at the University of Konstanz, to learn about their DSpace repository named “KOPS”.

What’s your role with DSpace at your organization or institution?

I am the Coordinator of the Software Development Team in the Department of Content-based Services. Some of our team's tasks are engineering requirements as well as the development of our institutional repository "KOPS" ("Konstanzer Online Publikations-system"). Being our IR, KOPS serves as the university's open access publication platform as well as organizational bibliography for the entire university. Since 2011, DSpace provides the software KOPS is based on.

Tell me a little about your organization or institution.

The Software Development Team is embedded in the Department of Content-based Services which is part of the "KIM", the Center of Communication, Information and Media at the University of Constance. The KIM incorporates all of the University's library and IT services, containing such different services as maintaining the e-mail infrastructure as well as operating the library.

Why did you decide on DSpace?

Around 2009 the decision was made to migrate the institutional repository to a different software base. The software used at that time did not meet the requirements and did not seem to keep up with current best practices and progress. To remain flexible and versatile, we preferred an open source solution for the institutional repository. After comparing the feature matrices of the products in question, the decision could quite easily be pinned down to using DSpace. Hosting by far more competence in Java than, for instance, in Perl, it seemed sensible to the department to move to DSpace. With a few years passed, we can confirm today that this was indeed a good decision.

What were your requirements going in?

We needed more flexibility and versatility than the prior software offered to us. Having a different open source product prior to DSpace, we had also noted at that time that it is quite important to choose a software product that is backed up by a robust, sound and uninterrupted development process leading to substantial feature enhancements on a regular basis. Flexible interfaces, a good support for in-house enhancements to the data model and a very configurable GUI layer were also important aspects.

What strategic organizational or institutional goals did DSpace help you meet?

Instead of waiting for specialized features being developed by a partner or the community, we are now able to just implement enhancements very specific to our organizational context. The very regular DSpace release policy makes it easy for us to just follow the product development cycles, making features available to our users with quite low latency. We are able to just define interfaces as they are needed, be it for other repositories, for our users or for our in-house customers. Furthermore, DSpace made it easy to us to start quite small and make the improvements as part of an ongoing process.

What are your plans for your DSpace repository in the future?

We are pleased to say that we see by far most of the tasks resolved, so I am tempted to just answer: "Keeping and enhancing it". But in fact, we are in a situation to meet requirements that are under ongoing change. To state an important example, we were very interested in features for easing up data integration from external data providers. It would be very comfortable to just synchronize publication data from providers of bibliographic data from the web. The most obvious example of such a feature would be some kind of configurable autocompletion feature that can just make suggestions for the publication referred to by the user while typing (thinking of "Did you mean this publication already listed by provider x?"). Having our users typing their data in a GUI form should not be the usual way to integrate publication data to the repository but just the last resort. Other valuable goals are a Sherpa/Romeo-integration that provides license information for our colleagues from the librarian services. Having reliable license information without research efforts would significantly ease up their work on the publication data.

What is at the top of your DSpace “wish list?

Currently, we face the situation that JSPUI and XMLUI have different feature sets and, in some cases, complementary strengths. Although having the choice between different technologies is more a strength than a weakness, we should not be forced to choose between different subsets of the feature list we would like to implement.

We would also love to see improvements with regard to fetching publication data from data providers over the web (as already mentioned above). That would be indeed highly appreciated and a great comfort.

What advice would you give to other organizations that are planning to establish a DSpace repository?

The decision for using DSpace as your IR requires adjusting DSpace to your organizational needs. DSpace is a very convenient, usable piece of software, but it ships in a "generic" state. So your organization may find itself on the way of transitioning from just running and configuring a software to a real software development process. Better not incommode your admins with the requirements of implementing features in DSpace, just hire developers. Have a rock-solid Java competence level in your organization. Know your software engineering best practices. Make the repository manager and the development team work together as reliable partners in mutual respect and faith. Respect the wishes of your users. Respect the requirements coming from the librarians who are forced to work with what you provide. Respect the requirement of having a professionally developed IR: our experiences suggest, that a single person is not sufficient to perform your DSpace integration and launch in a sensible amount of time. But when investing some resources, DSpace will make a sound, robust, performant, elegant and individual repository.

preserve