improve ISO19115-1 & ISO19115-2 to DCATUS data transfer

[rshewitt]

User Story

In order to improve the amount of data read from ISO19115-1 & -2 documents and written to DCATUS, datagov wants to enhance the read/write avenues of mdtranslator for ISO19115-1/-2 to DCATUS.

Acceptance Criteria

[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]

• GIVEN the current ISO19115-1/-2 to DCATUS mapping review doc
  AND a DCATUS field which can derive from multiple places within an ISO19115-1/-2 doc (e.g. "modified")
  WHEN a new read/write avenue is added
  THEN the data from the input doc is written to field in the output doc \

Background

according to our mapping rules for ISO19115-1/-2 to DCATUS it's common for DCATUS fields to accept values from multiple places within a ISO19115-1/-2 document. Take "rights" as an example, that value can be populated with data from 2 separate locations (legal and security constraints) within a -1/-2 doc.

1. //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:accessConstraints/gmd:MD_RestrictionCode
2. //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceConstraints/gmd:MD_SecurityConstraints/gmd:classification/gmd:MD_ClassificationCode

working on #4565 it was discovered that the output DCATUS transformation of this doc didn't have any distribution formats. this is because we're only writing from 1 of the acceptable roots ( e.g. //gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor ). by writing from the other acceptable root ( e.g. //gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions ) more information can be transferred from ISO19115-1/-2 to DCATUS.

Security Considerations (required)

Sketch

• create a sub-issue from this ticket for the exact read/write avenue you're adding ( e.g. path 2 of identifier. see mapping doc for more info )
• add necessary read functionality to pull data from input ISO19115-1/-2 doc into internal mdjson object
• add necessary write functionality to DCATUS

[rshewitt]

@btylerburton this is an important ticket to go to whenever information is missing from the transformation process ( not including the DCATUS-to-CKAN transformation ) because it can explain why something wasn't transferred between docs. this ticket pairs well with #5096. as data transfer improves then transformation can be rerun and more content can be on ckan.

[rshewitt]

publisher > subOrganizationOf is an example of something which can be added