We held a requirements chat on the topic of the DSpace deposit process on 17 September in the DSpace IRC channel.

BATCH IMPORT

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.

Other suggestions:

• 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

DEPOSIT INTERFACE

Suggestions included:

• 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.