Page History
Warning | ||
---|---|---|
| ||
This page represented a temporary discussion area around issues found in how these features were implemented in an early version of DSpace 7 (pre-7.0). A refactoring of these features has been designed/moved forward into this REST Contract PR: https://github.com/DSpace/Rest7Contract/pull/128. This is planned to be implemented by DSpace 7.0 beta 3 Therefore, this page is now OBSOLETE and the REST CONTRACT should be considered the latest version. |
Note |
---|
Draft notes (not complete or finalized). Based loosely on conversation in https://github.com/DSpace/DSpace/pull/2743 |
...
- Value-pairs were always enabled and act like a simply form of controlled vocabulary. They were only used to populate dropdowns in submission.
- 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
- 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
- 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
- This is disabled by default. When enabled, both value-pairs and controlled vocabularies could be used as authority control on a specific field(s).
- 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
...
- 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.
- 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
- 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, …
- This will have a side effect for some other tools.
- 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")
- 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
- OAI-PMH uses XML following the XOAI schema. This XML is run through XSLT to generate the XML to provide for different metadata formats in OAI-PMH. Values coming from authority control are provided different in XOAI than "normal" metadata values. Either a lot or institutions have to change their XSLTs or we do change how XOAI XML deals with authority control.
- 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).
- 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.
Overview
Content Tools