[Dspace-general] Chat summary: 17 September 2008

[Dorothea Salo]

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.

Dorothea

-- 
Dorothea Salo dsalo at library.wisc.edu
Digital Repository Librarian AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493