Incorrect mappings to SPASE

[rebeccaringuette]

This issue details the mappings from HAPI to SPASE that are found to be incorrect based on the mapping spreadsheet. Split from the comments in issue hapi-server/data-specification#279.

TestData2.0/dataset1.json

1. revision history container not created. should be under ResourceHeader:

<RevisionHistory>
  <RevisionEvent>
    <ReleaseDate>2021-04-27T15:38:11Z</ReleaseDate>
    <Note>Only known prior ReleaseDate of the metadata</Note>
  </RevisionEvent>
</RevisionHistory>

2. The AccessURL/Name field is populated but the about link for this server is not found (https://hapi-server.org/servers/TestData2.0/hapi/about). The value makes sense, but where did it come from? Same question for the entry in the Contact container. What is the desired behavior when no information is available?
3. Noting the second AccessInformation container, will this be done for all SPASE records drafted from HAPI?
4. Extra format values compared to the capabilities endpoint in the second AccessInformation container (png, svg, pdf).
5. Why is this link in both the AccessURL and the InformationURL fields? https://hapi-server.org/servers/#server=TestData2.0&dataset=dataset1

TestData3.3/dataset1.json

1. info/location has information, but is not mapped into a SpatialCoverage container in SPASE.
2. info/additionalMetadata/contentURL is populated, resulting in "https://hapi-server.org/servers/#server=TestData3.3&dataset=dataset1" being the URL in two InformationURL fields.
3. info/datasetCitation is populated, but not mapped to NumericalData/ResourceHeader/DOI

TestData3.3/datasets 2 and 3

TestData3.3/dataset2.json

1. https://hapi-server.org/servers/#server=TestData3.3&dataset=dataset1 is incorrectly included in the second InformationURL container.
2. info/geolocation has information, but is not mapped into a SpatialCoverage container in SPASE.

TestData3.3/dataset3.json

1. only one InformationURL container is present, compared to the double approach in all the others.
2. info/licenseURL is populated, but not mapped to RightsURI
3. info/warning is populated, but not mapped to Caveats
4. info/geolocation has information, but is not mapped into a SpatialCoverage container in SPASE.

[rebeccaringuette]

Bob, please check this statement: The mapping from info/geolocation into SPASE is incorrect due to differences in supporting coordinate system of each field on the SPASE side. Remove from the mapping?

[rebeccaringuette]

Update on the snowman example: no issues detected other than those already mentioned. Only one InformationURL container is produced compared to the double approach noted in other records. Also see the double approach on the AccessURL containers, but here the content looks good.