Page History

...

Simple choice management for DSpace submission forms

This is a template page for a new DSpace contribution. If you are unsure about the appropriate format or content, just look at this example. This page can be copied and used to fill out your new documentation.

Make sure you do NOT use Heading level 1, and stick to level 2 as the highest level in your document. Level one is reserved for the top level headings in the PDF version of the documentation.

The DSpace Submission forms, defined in the input-forms.xml file, allows the inclusion of value pairs that can be organized in lists in order to populate dropdowns or other multiple choice elements. If you explore the default input-forms.xml file, you can see that a number of such value pair lists are already pre defined.

Example

<value-pairs value-pairs-name="common_identifiers" dc-term="identifier">
    <pair>
        <displayed-value>Gov't Doc #</displayed-value>

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||
|F|M|T|1389620440889|          |bram|Use Case and high level benefits. Can someone with limited technical background understand what this is about?|
|F|M|T|1389620638059|<stored-value>govdoc</stored-value>
    </pair>
    <pair>
        <displayed-value>URI</displayed-value>
        <stored-value>uri</stored-value>
  |bram|Step by step</pair>
 how to use. Can<pair>
 someone with limited technical background use the feature?|
|F|M|T|1389620491621| <displayed-value>ISBN</displayed-value>
        <stored-value>isbn</stored-value>
  |bram|Technical implementation details. Did you provide enough details for other developers to add or extend on your work?|
|F|M|T|1389620524789|  </pair>
</value-pairs>

It generates the following HTML, which results in the menu widget below. 

<select name="identifier_qualifier_0">
    <option VALUE="govdoc">Gov't Doc #</option>
    <option VALUE="uri">URI</option>
    <option VALUE="isbn">ISBN</option>
</select>

 A list of value pairs has following required attributes:

• value-pairs-name – Name by which an input-type refers to this list.
• dc-term – Dublin Core field for which this choice list is selecting a value. 

Each value-pairs element contains a sequence of pair sub-elements, each of which in turn contains two elements:

• displayed-value – Name shown (on the web page) for the menu entry.
• stored-value – Value stored in the DC element when this entry is chosen. Unlike the HTML select tag, there is no way to indicate one of the entries should be the default, so the first entry is always the default choice.

Hierarchical Taxonomies and Controlled Vocabularies

The value pairs system works great for short and flat lists of choices. DSpace offers a second way of structuring and managing more complex, hierarchical controlled vocabularies. In contrast to the value pairs system, these controlled vocabularies are managed in separate XML files in the [dspace]/config/controlled-vocabularies/ directory instead of being entered straight into input-forms.xml

The taxonomies are described in XML according to this structure:

<node id="acmccs98" label="ACMCCS98">
    <isComposedBy>
         |bram|Configuration. Did you describe which aspects of your contribution can be configured and where configuration happens?|
|F|M|T|1389620576924|<node id="A." label="General Literature">
            <isComposedBy>
               |bram|Template text cleanup. Have you removed the template text that was initially included on this page?|
|F|M|F|1389620841679|<node id="A.0" label="GENERAL"/>
                <node id="A.1" label="INTRODUCTORY AND SURVEY"/>
               |bram|Installation details. If your functionality will not be enabled by default in DSpace, provide details on how the functionality can be installed or enabled.|

Use case and high level benefits

Describe which need the contribution is fulfilling and why it was originally created. Screenshots are always nice and will make people enthusiastic about your contribution.

Installation

If it takes any work to enable the contribution, please elaborate in detail. It is recommended that you provide a good default configuration so that your configuration can run straight out of the box.

Technical Implementation Details

If there are any possibilities to customize the contribution, it is good to provide some details on your implementation, or which design decisions have been taken.

Sub headings are generally fine

Recommended so that people can easily navigate using the Table of Contents at the top.

but don't

drive it too far

Heading 5 is generally not used and has no visual difference with heading 4. When in doubt, don't use Heading lvl 5.

Configuration

Explain which configuration parameters are available, in which files they can be found and which procedure is required for updating. Does it require a rebuild or is a tomcat restart enough, etc?

Where should I put my page? (DELETE this section from template when finished)

Here is a very short introduction to the hierarchy of the documentation. when in doubt, put your page straight under Using DSpace.

...

• Ingesting Content and Metadata: relevant section if your feature is related to the creation of content in DSpace
• Exporting Content and Metadata: relevant section for getting content out of DSpace

...

• Command Line Operations: important page that you can edit if your new contribution introduces any new command line operations.

 ...
            </isComposedBy>
        </node>
        ...
    </isComposedBy>
</node>

As you can see, each node element has an id and label attribute. It can contain the isComposedBy element, which in its turn, consists of a list of other nodes.

You are free to use any application you want to create your controlled vocabularies. A simple text editor should be enough for small projects. Bigger projects will require more complex tools. You may use Protegé to create your taxonomies, save them as OWL and then use a XML Stylesheet (XSLT) to transform your documents to the appropriate format. Future enhancements to this add-on should make it compatible with standard schemas such as OWL or RDF.

How to invoke a controlled vocabulary from input-forms.xml

Vocabularies need to be associated with the correspondent DC metadata fields. Edit the file [dspace]/config/input-forms.xml and place a "vocabulary" tag under the "field" element that you want to control. Set value of the "vocabulary" element to the name of the file that contains the vocabulary, leaving out the extension (the add-on will only load files with extension "*.xml"). For example:

<field>
    <dc-schema>dc</dc-schema>
    <dc-element>subject</dc-element>
    <dc-qualifier></dc-qualifier>
    <repeatable>true</repeatable>
    <label>Subject Keywords</label>
    <input-type>onebox</input-type>
    <hint>Enter appropriate subject keywords or phrases below.</hint>
    <required></required>
    <vocabulary>srsc</vocabulary>
</field>

The vocabulary element has an optional boolean attribute closed that can be used to force input only with the Javascript of controlled-vocabulary add-on. The default behaviour (i.e. without this attribute) is as set closed="false". This allow the user also to enter values as free text, not selecting them from the controlled vocabulary.

The following vocabularies are currently available by default:

• nsi - nsi.xml - The Norwegian Science Index
• srsc - srsc.xml - Swedish Research Subject Categories

Authority Control: Enhancing DSpace metadata fields with Authority Keys

The aforementioned features only deal with text representations of controlled values. DSpace also offers support for adding authority keys and confidence values to a specific text value entered in a metadata field. The following terminology applies in the description of this area of DSpace functionality:

• Authority An authority is an external source of fixed values for a given domain, each unique value identified by a key. For example, the OCLC LC Name Authority Service, ORCID or VIAF.
• Authority Record The information associated with one of the values in an authority; may include alternate spellings and equivalent forms of the value, etc.
• Authority Key An opaque, hopefully persistent, identifier corresponding to exactly one record in the authority.

The fact that this functionality deals with external sources of authority makes it inherently different from the functionality for controlled vocabularies. Another difference is that the authority control is asserted everywhere metadata values are changed, including unattended/batch submission, LNI and SWORD package submission, and the administrative UI.

How it looks in the DSpace user interface

The difference between an authority controlled metadata field and a non-authority controlled metadata field can be seen in the Edit interface for an accepted item.

Image Added

This example shows a value for an author name that has been linked with an authority key. The green thumb represents the associated confidence value "Accepted": This authority value has been confirmed as accurate by an interactive user or authoritative policy.

How it works

TODO

Original source:

Authority Control of Metadata Values original development proposal for DSpace 1.6

...