We held a requirements chat on the topic of the DSpace deposit process on 17 September in the DSpace IRC channel.
The commonest use-case for the batch import mechanism is receipt of a great many items at once. HTML items are another use-case. Most chatters had written custom code (outside DSpace altogether) to make batch-importing easier. It was suggested that a DSpace-blessed way to share, discover, and reuse some of this code would be helpful, as would translators from common metadata formats such as MARC and MODS to a format compatible with SWORD-based deposit. It might be possible to distribute third-party code in /contrib, which by convention does not warrant any particular code quality.
- a validator (or better error-handling) for batch imports; the -t flag does not catch many metadata errors, which can cause a batch import to die in the middle.
- a web interface to handle batch imports
- a web interface for altering input-forms.xml
- being able to select an input form "on the fly" based on the type of item being deposited
- a web interface to the Configurable Submission System
- eliminating the need to restart the server after changes to input-forms.xml and the Configurable Submission System
- allowing more configuration (e.g. input-forms.xml, Configurable Submission) and command-line actions (e.g. batch imports) to be pushed down to community and collection administrators
- allowing metadata specific to an eperson (e.g. name, metadata fields to exclude) to be stored in that eperson's profile
It was noted that the lack of a web interface to many DSpace configuration files means that repository managers who are not also systems administrators may not be able to configure their installations fully.