Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Draft notes (not complete or finalized).  Based loosely on conversation in

How this worked in DSpace 6

Three concepts:

Default settings:

  1. Value-pairs were always enabled and act like a simply form of controlled vocabulary.  They were only used to populate dropdowns in submission.
  2. Additional controlled vocabularies were disabled by default. Though they could be enabled for JSPUI only:
  3. Authority control was also disabled by default, though a variety of plugins were available out-of-the box for Library of Congress, SHERPA Romeo and ORCID:
    1. It was also possible to optionally configure Authority Control to use value-pairs and/or controlled vocabularies.  See
      1. When enabled, both value-pairs and controlled vocabularies could be used as authority control on a specific field(s).

How this is working in DSpace 7.0 beta2

  1. (Same/Similar behavior) Value-pairs are still always enabled in the new submission-forms.xml:
  2. (Different behavior) Additional controlled vocabularies are enabled by default, as they are configured to be used in Authority Control:
  3. (Different behavior) Authority control is enabled by default, and defaults it using both value-pairs and controlled vocabularies:
  4. (Different behavior) The Submission configuration/UI now only uses Authority Control for dropdowns, as both value-pairs and controlled vocabularies are authority control enabled.  See early notes at Configuration changes in the submission process
    1. (Same/Similar behavior) Controlled Vocabularies can be associated with a field via the <vocabulary> tag in submission-forms.xml:
    2. (Same/Similar behavior) Value-pairs can be associated with a field via the <input-type value-pairs-name="name">dropdown</input-type> tag. For example:

These behaviors primarily changed in

Side effects of new behavior in 7.0 beta2

  1. Because all value-pairs and controlled vocabulary are authority controlled by default, all metadata fields generated from either now have "authority IDs".  This makes them look/act different from DSpace 6 metadata.
    1. For value-pairs, the authority ID is the stored value.  So, e.g. "Book" has an authority ID of "Book". See examples in REST Contract:
    2. This will have a side effect for some other tools. 
      1. For example, Batch Metadata Editing separates authorities from values via a "::".  So, a dc.type value of "Book" will now appear as "Book::Book" in a CSV exported spreadsheet (whereas it used to appear just as "Book")
  2. The Authority ID doesn't add any additional information to the field. In fact, it's not a unique Identifier.  As a basic example, both the value-pairs for "common_identifiers" and "common_types" include an "Other" option.  So a value linking to Authority ID "Other" cannot be mapped back to its source without finding the "submission-form.xml" which was used to create it (and that configuration may have been modified since then).
    1. This behavior was identical in DSpace 6, if you used value-pairs as Authority Control.  But, as noted above, this feature was disabled by default.
  • No labels