Experimental dataset JSON GET API returns multi-valued fields as arrays

[stevenwinship]

What this PR does / why we need it: For API GET /api/datasets/{id}/metadata multi-valued field values are not returned as arrays if only 1 entry exists. This causes parsing the JSON to be more complex.

Which issue(s) this PR closes: #9495

• Closes Experimental dataset JSON GET API doesn't return multi-valued fields as arrays #9495

Special notes for your reviewer: Since the fields are parsed as an array, when more than 1 entry exists, there is no break in backward compatibility.

Suggestions on how to test this: Create a dataset with 1 subject and another with more than 1 subject. Examine the JSON output to see that the "subject": ["Medicine, Health and Life Sciences"] is always surrounded with []. This will happen for all fields that have DatasetFieldType.isAllowMultiples() (for reference "title" does not allow multiples)

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?: Included

Additional documentation:

[qqmyers]

If you make changes to the OREMap, you need to update the version as noted at

dataverse/src/main/java/edu/harvard/iq/dataverse/util/bagit/OREMap.java

Lines 49 to 50 in 8037242

	//NOTE: Update this value whenever the output of this class is changed
	private static final String DATAVERSE_ORE_FORMAT_VERSION = "Dataverse OREMap Format v1.0.3";

. This could also break archiving and tools such as DVUploader that can read archival bags to restore datasets. Hopefully those are robust enough to this change, but they presumably have code to parse single values that will now be obsolete.

[stevenwinship]

I will update the version (even though the output really doesn't change) and check DVUploader. DVUploader and anyone using the API should have no issue with the array since it is there when more than 1 entry is there.

[stevenwinship]

It looks like DVUploader expects an array. When it finds a String it converts it to an array so I believe this code is not affected by this change.

[qqmyers]

Thanks for checking. Thinking some more, I think most of the places we read the ORE map, we use json-ld tools and canonicalize the format before parsing, which probably managed the conversion already. (That would probably be a best practice for json-ld in general.)

[coveralls]

coverage: 25.021% (+6.2%) from 18.845% — 9495-return-multi-valued-fields-as-arrays into develop

[github-actions]

Test Results

403 tests  ±0   388 ✅ ±0   37m 21s ⏱️ -2s
 55 suites ±0    15 💤 ±0 
 55 files   ±0     0 ❌ ±0 

Results for commit 3e3fed7. ± Comparison against base commit 741c5da.

♻️ This comment has been updated with latest results.

[qqmyers]

This looks OK. I edited the release note to indicate there are two api calls and one is only if JSON LD is requested.

In QA, I think someone should verify that the PUT will accept the new formatting (so we maintain round-tripping). I think it will, because the PUT uses a JSON-LD library that standardizes what we actually try to parse (The 'same' JSON-LD can be written with many variants of the @context so standardizing (or completely parsing as JSON-LD) is necessary for inputs.)

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:9495-return-multi-valued-fields-as-arrays

ghcr.io/gdcc/configbaker:9495-return-multi-valued-fields-as-arrays

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.