Versions Compared

Key

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

...

and will be changed to return options to present in the UI not directly related with an authority value, i.e.

Code Block
titleexample from a value pair
{
	"_embedded": {
		"authorityChoices": [
		{
			"display": "Animation",
			"value": "Animation",
			"type": "authorityChoice"
		},
        {
			"display": "Article",
			"value": "Article",
			"type": "authorityChoice"
		},
        {
			"display": "Book",
			"value": "Book",
			"type": "authorityChoice"
		},
…


Code Block
titleexample from the ORCID Authority
{
	"_embedded": {
		"authorityChoices": [
		{
			"display": "Bollini, AndreaDataset",
			"value": "datasetBollini, Andrea",
			"authority": where available and need to be stored "will be generated::orcid::0000-0002-9029-1854",
			"otherInformation": {
				"first-name":"Andrea",
				"last-name": "Bollini",
				"orcid": "0000-0002-9029-1854"
			},
			"type": "authorityChoice",
			"_links": {
				"authorityValue": {
					"href": "https://dspace7.4science.cloud/server/api/integration/authorityValues/ORCID:will be generated::orcid::0000-0002-9029-1854"
				}
			}
		},
…

please note that the above authority value from the Orcidv2AuthorityValue is exactly as it is today when the value is not yet stored in SOLR

Code Block
titleexample from the srsc controlled vocabulary
{
	"_embedded": {
		"authorityChoices": [
		{
			"display": "History of religion",
			"value": "Research Subject Categories::HUMANITIES and RELIGION::Religion/Theology::History of religion",
			"otherInformation": {
				"note": "Religionshistoria"
			},
			"type": "authorityChoice",
			"_links": {
				"authorityValue": {
					"href": "https://dspace7.4science.cloud/server/api/integration/authorityValues/srsc:VR110102"
				}
			}
		},
		{
			"display": "Church studies",
			"value": "Research Subject Categories::HUMANITIES and RELIGION::Religion/Theology::Church studies",
			"otherInformation": {
				"note": "Kyrkovetenskap"
			},
			"type": "authorityChoice",
			"_links": {
				"authorityValue": {
					"href": "https://dspace7.4science.cloud/server/api/integration/authorityValues/srsc:VR110103"
				}
			}
		},
…
		{
				-- if there are an authority"display": "Religion/Theology",
			"value": "Research Subject Categories::HUMANITIES and RELIGION::Religion/Theology",
			"type": "authorityChoice",
			"_links": {
				"authorityValue": {
					"href": "https://dspace7.4science.cloud/server/api/integration/authorityValues/<authority-name>:<authority-ID>srsc:SCB110"
				}
			}
		},
…

the display value is what we expect that the Angular UI (or any other REST client) will show to the user. The value and eventually the authority are what the client should store in the metadatavalue, i.e. should use in the subsequent PATCH request.


the relevant changes here are
there is not anymore an ID attribute, as this object is not directly addressable in the URL
the _link section eventually contains a reference to an authorityValue but there is not self link
Please note that the existence of an authority will not imply that an authority id must be stored. If the authority value must be stored or not when available will be indicated by a new attribute in the authority endpoint

...

to indicate that the search must use the getBestMatch method of the authority framework and only return the first Choice that matches exactly with the authority if provided or with the value. This parameter will be used by angular to retrieve the Choice related to an existing metadatavalue (i.e. when a submission is resumed) as the display value must be shown to the user instead of the stored value. In the case that no result is found the angular application will be free to prompt an alert or keep the current value displaying it as is.

A new endpoint
https://dspace7.4science.cloud/server/api/integration/authorityValues/<authority-name>:<authority-IDID>>
will be implemented supporting only direct GET request to a specific ID.
This endpoint is needed to provide a persistent direct access to authority value and support the Controlled-Vocabulary hierarchical visualization via the additional search methods included here https://github.com/DSpace/Rest7Contract/pull/120 (to be updated according to the new proposed endpoint /integration/authorityValues)

Please note that the ID will be a combination of the authority pluginname and the authority value usually stored in the metadata. There is not plan to change what is eventually stored (as the authority ID is not necessarily stored) in the metadatavalue, the authority pluginname will be retrieved when necessary via a new search method.

...

Finally, the hierarchical controlled vocabulary feature will be supported thanks to the search methods proposed in https://github.com/DSpace/Rest7Contract/pull/120 (to be updated according to the new endpoints structure). There will be not need to store the authority ID in the metadata value also for controlled vocabulary but we will always auto generate a temporary ID to allow the navigation of the controlled vocabulary tree if the ID is not present in the controlled vocabulary xml definition file.


Estimation: all the above changes are expected to have a limited impact on the Angular side, both for existing features in the master (value-pairs, authority lookup & suggestion) than on the ongoing development (controlled-vocabulary). To make these changes we estimate 4-8 hours of work on the Angular side. On the REST side more work is required, we estimate an effort in the range of 3-5 days