Page History

...

The DSpace Submission process consists of a series of "steps", where each "step" corresponds to one or more UI pages"sections" in the Submission UI. By default, the DSpace Submission process includes the following steps/sections, in this order:

1. "Select Collection" step" (id="collection"), appears as dropdown: If not already selected, the user must select a collection to deposit the Item into.  As of DSpace 7, you also can change the Collection you are submitting into at any time. However, be aware that there may be some metadata lost if the Collection you switch two uses a different submission form & you already began entering metadata in the current submission.
2. "Describe" step" sections (id="traditionalpageone" and "traditionalpagetwo"):  This is where the user may enter descriptive metadata about the Item. This step may consist of one or more pages sections of metadata entry. By default, there are two pages sections of metadata-entry . For information on modifying the metadata entry pages, please see Custom Metadata-entry Pages for Submission section below.
3. "Upload" stepsection (id="upload"): This is where the user may upload one or more files to associate with the Item.   For more information on file upload, also see As of DSpace 7, you can also drag and drop files anywhere on the page to trigger an upload. For more information on file upload, also see Configuring the File Upload step below.
4. "Review" step: This is where the user may review all previous information entered, and correct anything as needed."License" stepLicense" section (id="license"): This is where the user must agree to the repository distribution license in order to complete the deposit.  This repository distribution license is defined in the [dspace]/config/default.license file. It can also be customized per-collection from the Collection Admin Edit UI.  If you are using XMLUI, the default license may be formatted using Simple HTML Fragment Markup.
5. "Deposit" button: Once all required fields/sections are completed, the "Deposit" button becomes enabled.  After clicking it, the new "Complete" step: The deposit is now completed. The Item will either become immediately available or undergo a workflow approval process (depending on the Collection policies).  For more information on the workflow approval process see : Configurable Workflow; for "traditional" workflow see also the section "The Manual DSpace Submission and Workflow System" in Functional Overview. Configurable Workflow

To modify or reorganize these submission To modify or reorganize these submission steps, just modify the [dspace]/config/item-submission.xml file. Please see the section below on Reordering/Removing/Adding Submission Steps.

You can also choose to have different submission processes for different DSpace Collections. For more details, please see the section below on Assigning a custom Submission Process to a Collection.

...

Optional Steps

...

DSpace also ships with several optional steps which you may choose to enable if you wish.  In no particular order:

• "Access" step (NOT YET AVAILABLE in 7.0, but coming soon)

...

Optional Steps

DSpace also ships with several optional steps which you may choose to enable if you wish.  In no particular order:

• "Access" step: This step allows the user to (optionally) modify access rights or set an embargo during the deposit of an Item. For more information on this step, and Embargo options in general, please see the Embargo documentation.
• "CC License" step (id="cclicense"): This step allows the user to (optionally) assign a Creative Commons license to a particular Item. Please see the Configuring Creative Commons License section of the Configuration documentation for more details.
• "Start Submission LookupExtraction" step (id="extractionstep"): This step allows the user to search or load metadata from an external service (arXiv online, bibtex file, etc.) and prefill will automatically attempt to extract metadata from uploaded files and populate it in the submission form. For more information on enabling and using it, please see the section on Configuring StartSubmissionLookupStep below."Initial Questions" step: This step asks users a simple set of "initial questions" which help to determine which metadata fields are displayed in the "Describe" step (see above).  These initial questions include:
• Multiple Titles: The item has more than one title, e.g. a translated title  (If selected, then users will be asked for an alternative title in the Describe step)
  

Published Before: The item has been published or publicly distributed before (If selected, then users will be asked for a publication date and publisher in the Describe step).


Warning
title Initial Questions will auto-assign a publication date when "Published Before" is unselected
Please note, if you enable Initial Questions, and your users do NOT select "Published Before" option, then DSpace will auto-assign a publication date (dc.date.issued) to that particular Item. It may be entirely accurate for some types of content (e.g. for gray literature or even theses/dissertations) to auto-assign this publication date.  As such, you may wish to still enable "Initial Questions" if your repository is mainly for previously unpublished content. You may also choose to only enable it for specific Collections – see Assigning a custom Submission Process to a Collection section below. However, if the Item actually was published in some other location, this will result in an incorrect publication date being reported by DSpace.  This tendency for an incorrect publication date has been reported by Google Scholar to DSpace developers (see: DS-1481), which is why the "Initial Questions" are now disabled by default (see DS-1655).

To enable any of these optional submission steps, just uncomment the step definition within the [dspace]/config/item-submission.xml file. Please see the section below on Reordering/Removing/Adding Submission Steps.

You can also choose to enable certain steps only for specific DSpace Collections. For more details, please see the section below on Assigning a custom Submission Process to a Collection.

Understanding the Submission Configuration File

The [dspace]/config/item-submission.xml contains the submission configurations for both the DSpace JSP user interface (JSPUI) or the DSpace XML user interface (XMLUI or Manakin). This configuration file contains detailed documentation within the file itself, which should help you better understand how to best utilize it.

The Structure of item-submission.xml

• By default it is disabled, as it populates metadata automatically (without notifying the user). 
• Various Configurable Entities related steps: These steps are "Describe" steps that are specific to different Entity types. They provide a list of metadata fields of specific interest to those Entities. 

To enable any of these optional submission steps, just uncomment the step definition within the [dspace]/config/item-submission.xml file. Please see the section below on Reordering/Removing/Adding Submission Steps.

You can also choose to enable certain steps only for specific DSpace Collections. For more details, please see the section below on Assigning a custom Submission Process to a Collection.

Understanding the Submission Configuration File

The [dspace]/config/item-submission.xml contains the submission configurations for both the DSpace JSP user interface (JSPUI) or the DSpace XML user interface (XMLUI or Manakin). This configuration file contains detailed documentation within the file itself, which should help you better understand how to best utilize it.

The Structure of item-submission.xml

<item-submission>
	<!-- Where submission processes are mapped to specific Collections -->
	<submission-map>
	<name-map collection-handle="default" submission-name="traditional" /> ...
	</submission-map>

<item-submission>
	<!-- Where submission"steps" processeswhich are mappedused toacross specificmany Collections -->
	<submission-map>
	<name-map collection-handle="default" submission-name="traditional" /> ...
	</submission-map>
	<!-- Where "steps" which are used across many submission processes submission processes can be defined in a
	   single place. They can then be referred to by ID later. -->
	<step-definitions>
	<step id="collection">
	<processing-class>org.dspace.submit.step.SelectCollectionStep</process;/processing-class>
	<workflow-editable>false</workflow-editable>
	</step>
		...
	</step-definitions>
	<!-- Where actual submission processes are defined and given names. Each <submission-process> has
	   many <step> nodes which are in the order that the steps should be in.-->
	<submission-definitions> <submission-process name="traditional">
	    ...
	<!-- Step definitions appear here! -->
	</submission-process>
	    ...
	</submission-definitions>
	</item-submission>

...

When StartSubmissionLookupStep is enabled, the user comes up with the following screen when a new submission is initiated:

...

There are four accordion tabs (default configuration hides the third tab):

...

2) Upload a file: In this tab, the user can upload a file, select the type (bibtex. csv, etc.), see the publications in the "Results" tab and then either select one to proceed with the submission or make all of them "Workspace Items" that can be found in the "Unfinished Submissions" section in the "My DSpace" page.

...

The "preview mode" in the figure above has the following functionality:

...

Normally, you do not need to touch any of these three properties. You can edit the reference beans instead.

<bean id="multipleDataLoader" />

...

in such a case, your data loader key will appear as a provider in the "Search for identifier" accordion tab 

<bean id="bibTeXDataLoader" />
<bean id="csvDataLoader" />
<bean id="tsvDataLoader" />
<bean id="risDataLoader" />
<bean id="endnoteDataLoader" />
<bean id="pubmedFileDataLoader" />
<bean id="arXivFileDataLoader" />
<bean id="crossRefFileDataLoader" />
<bean id="ciniiFileDataLoader" />
<bean id="pubmedOnlineDataLoader" />
<bean id="arXivOnlineDataLoader" />
<bean id="crossRefOnlineDataLoader" />
<bean id="ciniiOnlineDataLoader" />

...

b) maxResults: the maximum results that these services will reply with to your search. By default, this property is commented out while the default value is 10 for both services. 

(Regarding the file dataloaders, you can find the attached file named "sample-files.zip" that contains samples of all the file types that the corresponding data loaders can handle)

<bean id="phase1LinearWorkflow" />

This bean specifies the processing steps to be applied to the records metadata before they proceed to the output generator of the transformation engine. Currenty, three steps are supported, but you can add yours as well.

<bean id="mapConverter_arxivSubject" />
<bean id="mapConverter_pubstatusPubmed" />
<bean id="removeLastDot" />

...

These beans are the processing steps that are supported by the 2nd phase of transformation engine. The first merges the values of multiple keys to a new key. The second one concatenates the values of a specific key to a unique value. The third one translated the three-letters language code to two-letters one (ie: eng to en)

<bean id="org.dspace.submit.lookup.DSpaceWorkspaceItemOutputGenerator" />

...

a) outputMap: A map from the intermediate keys to the DSpace metadata schema fields. The table below displays the default output mapping. As you can see, some fields, while the are read from the input source, are not output in DSpace since there are no default metadata schema fields to host them. However, if you create the corresponding metadata field registry, you can come back in this configuration to add a map between the input field key and the DSpace metadata field.

b) extraMetadataToKeep: A list of DSpace metadata schema fields to keep in the output

The following table presents the available keys from the online services, the keys that BTE uses in phase1 and the final output map to DSpace metadata fields.

you can come back in this configuration to add a map between the input field key and the DSpace metadata field.

b) extraMetadataToKeep: A list of DSpace metadata schema fields to keep in the output

The following table presents the available keys from the online services, the keys that BTE uses in phase1 and the final output map to DSpace metadata fields.

...

...