Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L1809
  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: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L1432-L1437
    1. It was also possible to optionally configure Authority Control to use value-pairs and/or controlled vocabularies.  See https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L1462-L146
      1. This is disabled by default. When enabled, both value-pairs and controlled vocabularies could be used as authority control on a specific field(s).

...

  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: https://github.com/DSpace/Rest7Contract/blob/master/authorities.md#authority-entry-values
    2. Other values in the same field don't have an authority ID, e.g. values from an upgraded DSpace 6 or values from another collection which uses the same field as plain text, or values submitted through SWORD, …
    3. 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. Discovery has always treated authority values separate in both search and browse. Values with an authority ID are displayed separate from values without an authority ID
  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.