...
Submission and Workflow B.O.F
(1) Need for more information to enter and store for several fields
Many bibliographic systems, like Aleph, have resolutions for this and call it subfields.
...
Example (2) is the author-field where there is a need to store also email address and some unique number (Digital Author Identiefier). This unique Author ID is needed to make lists of works from the same author easily, to generate lists of author works made in multiple universities and eg to identify that an author has published with different names (before and after marriage p.e) but in fact is the same person. Furthermore the option is required to call external routines to show a list of authors (like from SAP or from a nation-wide author-thesaurus as available in the Netherlands at Pica). The University of Leuven (Lieven Droogmans) demonstrated a possible solution for what is required on authors.
(2) Need for specification of input-forms.xml on document-type rather than collection or community.
Although the current collection or community level is very nice and a big improvement, many institutions store multiple document types in a single collection. And each document type requires a different set of metadata fields to maintain. Now institutions create workarounds to organize collections by document-type. Specification at document-type level therefore would be needed.
(3) Possibility to move items to other collections
Possibility to move an item to another collection during the submission process. This to correct mistakes during submission. Now that is impossible and the author has to re-enter all data
Possibility to move an item to another collection when finalized in dspace. This is needed and handsome when eg. re-organizing collections.
(4) Possibility to upload items directly into multiple collections
Would be nice during submission to directly be able to specify multiple collections. Currently this must be done afterwards, after submission, by administrative people. One of the examples was also 'automapper' (not in the standard dspace), but manually during submission are needed as well.
(5) Store a URL to a bitstream rather than the bitstream itself
Is handsome when the bitstreams are huge (video streams) or when the bitstreams are available elsewhere in another repository or at a commercial publisher.
(6) Propose example values and/or default values in input-forms.xml
Examples given during data-entry greatly clarify how users should enter fields during submission.
Proposing defaults would greatly reduce the amount of work for a user during submission while leaving the option open to deviate from the default.
(7) Possibility for hiding bitstreams and relating bitstreams to each other.
example (1)
Uploading a word document which must be hidden in the UI and uploading (or generating) the related pdf-file which must be shown.
...