Difference between revisions of "SUNScholar/Submission System"

From Libopedia
Jump to navigation Jump to search
m
 
(52 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Introduction==
+
<center>
{{WARNING}}
+
'''[[SUNScholar/Operational_Guide|BACK TO OPERATIONAL GUIDE]]'''
 +
</center>
  
Items are submitted to collections using forms. Each collection can have its own customised submission forms and these forms can also have customised pages. Below is information about form pages and collection submissions.
+
===Introduction===
 +
Items are submitted to collections using workflow steps with forms. Each collection can have its own customised submission steps and forms.
  
==[[SUNScholar/Submissions/Steps|Submission Steps]]==
+
===<font color="red">Please note:</font>===
 +
Researchers may complain of a submission process that is onerous and takes too much time. A possible remedy is to create very simple submission forms per faculty/school/department for "quick" submissions.
 +
After submission, then let the faculty/subject librarians perform the submission workflow of reviewer, or metadata editor and then move or map the item into the correct collection.
  
==Forms==
+
===[[SUNScholar/Submissions/Steps|Step 1 - Define submission steps, where each step has a form]]===
Go to the source folder by typing as follows:
 
cd /home/dspace/dspace-1.7.2-src-release/dspace/config
 
Edit the "input-forms.xml" file:
 
nano /home/dspace/dspace-1.7.2-src-release/dspace/config/input-forms.xml
 
Below are descriptions of the sections which can be customised.
 
===Form maps (form2collection map)===
 
Information from the file for setting up form maps.
 
<pre>
 
<!-- 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".                                    -->
 
</pre>
 
For example:
 
<pre>
 
<form-map>
 
  <name-map collection-handle="123456789/1" form-name="simple" />
 
</form-map>
 
</pre>
 
  
===Form definitions (form pages)===
+
===[[SUNScholar/Submissions/Forms|Step 2 - Define submission forms, as per the steps defined above and which may have custom input fields per form]]===
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'''.
+
===Step 3 - Activate new forms===
<pre>
 
<!-- 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.                          -->
 
</pre>
 
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.
 
<pre>
 
<!-- 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.                  -->
 
</pre>
 
 
 
{{NANO}}
 
 
 
==Notes==
 
 
 
* The <code>&lt;required&gt;</code> element contains the textual hint displayed to the submitter about why the field is required. Leave it empty for optional fields.
 
* The <code>&lt;vocabulary&gt;</code> element is optional.  It allows you to specify the controlled vocabulary that this field should select its values from.  This field also has an optional <code>closed</code> 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:<pre>&lt;vocabulary closed=”true”&gt;srsc&lt;/vocabulary&gt; </pre>
 
* 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, <code>srsc</code> references the vocabulary specified in the file located at ''[dspace]''/config/controlled-vocabularies/srsc.xml
 
* Valid input types (for <code>&lt;input-type&gt;</code>) 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 <code>value-pairs-name</code> attribute referring to the <code>&lt;value-pairs&gt;</code> list of allowed values.
 
** “qualdrop_value” (a textbox, which is preceded by a “qualifying” dropdown of values.  Requires a <code>value-pairs-name</code> attribute, similar to “dropdown”.  Also requires <code>&lt;repeatable&gt;</code> is set to “true”)
 
** “textarea” 
 
* Setting the <code>&lt;repeatable&gt;</code> 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==
 
 
{{REBUILD}}
 
{{REBUILD}}
  
==References==
+
===Tips===
*http://web.lib.sun.ac.za/dspace/docs/1.7.2/Submission%20User%20Interface.html
+
*http://www.slideshare.net/bramluyten/secrets-of-the-dspace-submission-form
* http://wiki.dspace.org/index.php/Alter_submission_input_forms
+
*https://wiki.duraspace.org/display/DSPACE/Alter+submission+input+forms
* http://di.tamu.edu/projects/xmlui/manakin/
+
*https://wiki.duraspace.org/display/DSPACE/Change+a+form+value
* http://cavlec.yarinareth.net/2008/01/07/the-dspace-batch-importer
+
*http://wiki.dspace.org/index.php/Alter_submission_input_forms
  
'''[[SUNScholar/Customisation|Back to Customisation]]'''
+
===References===
 +
*https://wiki.duraspace.org/display/DSDOC5x/Submission+User+Interface
 +
*https://wiki.duraspace.org/display/DSDOC4x/Submission+User+Interface
 +
*https://wiki.duraspace.org/display/DSDOC3x/Submission+User+Interface
 +
*http://dri.ie/vocabularies
 +
*http://thinkchecksubmit.org
 +
[[Category:Customisation]]

Latest revision as of 12:00, 28 May 2016

BACK TO OPERATIONAL GUIDE

Introduction

Items are submitted to collections using workflow steps with forms. Each collection can have its own customised submission steps and forms.

Please note:

Researchers may complain of a submission process that is onerous and takes too much time. A possible remedy is to create very simple submission forms per faculty/school/department for "quick" submissions. After submission, then let the faculty/subject librarians perform the submission workflow of reviewer, or metadata editor and then move or map the item into the correct collection.

Step 1 - Define submission steps, where each step has a form

Step 2 - Define submission forms, as per the steps defined above and which may have custom input fields per form

Step 3 - Activate new forms

Rebuild the DSpace webapps using the custom rebuild script.

Tips

References