Difference between revisions of "SUNScholar/Submission System"

From Libopedia
Jump to navigation Jump to search
 
m (1 revision)
(No difference)

Revision as of 10:54, 15 August 2010

Introduction

The workflows of Dspace can be customised per collection.

For each submission per collection you complete a page per step that has certain fields of data to be captured.

With DSpace you can define what data fields to capture per page and how many steps to complete per submission.

Create a "Test" collection using the web interface of your test Dspace server and memorise its handle id. This is used to map the custom definitions to the collection.

Now open a terminal and login to your test instance of Dspace. (You should know how-to do this by now ;-)

Forms

Go to the source folder by typing as follows:

cd /home/dspace/dspace-1.5.2-src-release/dspace/config

Edit the "input-forms.xml" file:

nano /home/dspace/dspace-1.5.2-src-release/dspace/config/input-forms.xml

Form maps (form2collection map)

Information from the file for setting up form maps.

 <!-- The form-map maps collection handles to forms. DSpace does not       -->
 <!-- require that a collection's name be unique, even within a community .-->
 <!-- DSpace does however insure that each collection's handle is unique.  -->
 <!-- Form-map provides the means to associate a unique collection name    -->
 <!-- with a form. The form-map also provides the special handle "default" -->
 <!-- (which is never a collection), here mapped to "traditional". Any     -->
 <!-- collection which does not appear in this map will be associated with -->
 <!-- the mapping for handle "default".                                    -->

For example:

 <form-map>
   <name-map collection-handle="123456789/1" form-name="simple" />
 </form-map>

Form definitions (metadata capture)

This is where you define what data is captured per page using the optional form common terms (controlled vocabularies) below.

Information from the file for setting up form definitions per form-name. Tip: Copy an existing definition to create a new one with a new form-name.

 <!-- The form-definitions map lays out the detailed definition of all the -->
 <!-- submission forms.Each separate form set has a unique name as an      -->
 <!-- attribute. This name matches one of the names in the form-map. One   -->
 <!-- named form set has the name "traditional"; as this name suggests,    -->
 <!-- it is the old style and is also the default, which gets used when    -->
 <!-- the specified collection has no correspondingly named form set.      -->
 <!--                                                                    -->
 <!-- Each form set contains an ordered set of pages; each page defines    -->
 <!-- one submission metadata entry screen. Each page has an ordered list  -->
 <!-- of field definitions, Each field definition corresponds to one       -->
 <!-- metadata  entry (a so-called row), which has a DC element name, a    -->
 <!-- displayed label, a text string prompt which is called a hint , and   -->
 <!-- an input-type. Each field also may hold optional elements: DC        -->
 <!-- qualifier name, a repeatable flag, and a text string whose presence  -->
 <!-- serves as a 'this field is required' flag.                          -->

Now you can customize the pages for the "simple" form by editing the pages in the new form-name definition.

Form common terms (controlled vocabularies)

This is where you define controlled vocabularies to be used per page per form per submission per collection.

 <!-- form-value-pairs populate dropdown and qualdrop-value lists.          -->
 <!-- The form-value-pairs element holds child elements named 'value-pairs' -->
 <!-- A 'value-pairs' element has a value-pairs-name and a dc-term          -->
 <!-- attribute. The dc-term attribute specifies which to which Dublin Core -->
 <!-- Term this set of value-pairs applies.                                 -->
 <!--     Current dc-terms are: identifier-pairs, type-pairs, and           -->
 <!--     language_iso-pairs. The name attribute matches a name             -->
 <!--     in the form-map, above.                                           -->
 <!-- A value-pair contains one 'pair' for each value displayed in the list -->
 <!-- Each pair contains a 'displayed-value' element and a 'stored-value'   -->
 <!-- element. A UI list displays the displayed-values, but the program     -->
 <!-- stores the associated stored-values in the database.                  -->

Save the file and exit.

Submissions

Go to the source folder by typing as follows:

cd /home/dspace/dspace-1.5.2-src-release/dspace/config

Edit the item-submission.xml file as follows:

nano /home/dspace/dspace-1.5.2-src-release/dspace/config/item-submission.xml
<!-- This XML configuration file allows you to configure the ordering     -->
<!-- and number of the steps that occur in the Item Submission Process.   -->

Submission maps (submission2collection map)

Information from the file for setting up submission maps.

<!-- The process-map maps collection handles to a particular Item         -->
<!-- Submission Process.  This requires that a collection's name be       -->
<!-- unique, even within a community. DSpace does however insure that each-->
<!-- collection's handle is unique.  Process-map provides the means to    -->
<!-- associate a unique collection name with an Item Submission process.  -->
<!-- The process-map also provides the special handle "default" (which is -->
<!-- never a collection), here mapped to "traditional". Any collection    -->
<!-- which does not appear in this map will be associated with the mapping-->
<!-- for handle "default".

For example:

<submission-map>
 <name-map collection-handle="123456789/1" submission-name="full" />
</submission-map>

Submission definitions (submission steps)

This is where you define what steps are completed per submission per collection.

Information from the file for submission definitions (workflows). Tip: Copy an existing definition to create a new one with a new process of name.

 <!-- The submission-definitions map lays out the detailed definition of   -->
 <!-- all the Item Submission Processes (and the ordering of their steps). -->
 <!-- Each separate "submission-process" has a unique name as an attribute,-->
 <!-- which matches one of the names in the process-map. One named         -->
 <!-- "submit-process" has the name "traditional"; as this name suggests,  -->
 <!-- it is the default item submission process, which gets used when      -->
 <!-- the specified collection has no correspondingly named submit-process.-->
 <!--                                                                      -->
 <!-- Each submit-process contains an ordered set of steps; each step      -->
 <!-- defines one "step" occurring during the process of submitting an     -->
 <!-- item.  A step can either be reference by 'id' (in which case it must -->
 <!-- be defined in <step-definitions> above), or defined completely here. -->

For example, the "full" workflow.

<submission-definitions>
 <submission-process name="full">
        <step>
          ...
        </step>
 </submission-process>
</submission-definitions>

Now you can customize the number of steps for the "full" workflow by editing the steps in the new submission process of name full.

Note: There must be a minimum of one step and a maximum of six steps.

Shared submission definitions (shared submission steps)

Information from the file for "shared" step definitions for submission processes.

 <!-- The 'step-definitions' allows you to define steps which you may wish -->
 <!-- to "share" amongst multiple submission-item definitions.  In order to-->
 <!-- share the same step definition, you can refer to it by its unique id -->
 <!-- defined in this section.  EVERY 'step' in this section MUST have a   -->
 <!-- unique identifier in the 'id' attribute!                             -->

Save the file and exit.

Notes

  • The <required> element contains the textual hint displayed to the submitter about why the field is required. Leave it empty for optional fields.
  • The <vocabulary> element is optional. It allows you to specify the controlled vocabulary (see Use Controlled Vocabularies for more information) that this field should select its values from. This field also has an optional closed attribute. If closed is set to true, a user can only select values from the controlled vocabulary. By default, closed is set to false, which allows a user to also enter in free text if he/she chooses. For example:
    <vocabulary closed=”true”>srsc</vocabulary> 
  • The name of the controlled vocabulary must correspond to the name of the XML file (without “.xml”) which contains the vocabulary. So, in the above example, srsc references the vocabulary specified in the file located at [dspace]/config/controlled-vocabularies/srsc.xml
  • Valid input types (for <input-type>) are:
    • “date”
    • “name” (two text boxes, labeled last and first name)
    • “onebox” (a one-line textbox)
    • “twobox” (two textboxes on a single line)
    • “dropdown” (for which you must specify a value-pairs-name attribute referring to the <value-pairs> list of allowed values.
    • “qualdrop_value” (a textbox, which is preceded by a “qualifying” dropdown of values. Requires a value-pairs-name attribute, similar to “dropdown”. Also requires <repeatable> is set to “true”)
    • “textarea”
  • Setting the <repeatable> element to “true” creates an “Add more” button, which allows you to add multiple values into that particular field. Examples of this include the authors and keywords fields in the standard DSpace submission process.

Activation of modified workflows

Find out how to rebuild DSpace by clicking here.

References