Closed keegansmith21 closed 11 months ago
Attention: 51 lines
in your changes are missing coverage. Please review.
Comparison is base (
fe25376
) 94.44% compared to head (b513765
) 93.29%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR was necessitated by two related quirks of the OAPEN metadata feed:
To fix these two abnormalities I have implemented the following solutions:
1. Related Product Elevation
For every RelatedProduct in the metadata feed, a new product is created that has this related product as its main identifier, and swaps out the RP identifier for that of the main product. This step is technically introducing fake metadata, so we only want to do it when necessary and definitely should not be applied to all publishers.
2. Related Product Normalisation
ONIX 3.0 specifies that each RelatedProduct should have only one ProductIdentifier. There is an exception to be made when there are identical ProductIdentifier elements with different ProductIDType values. This step will pull out unnecessary ProductIdentifier elements into their own RelatedProduct elements to conform with specification. This step should also only be necessary for select sources and not implemented into all ONIX transformations.
ONIX Transform Consolidation
With the addition of several new functions and steps in the oapen_metadata_telescope's transform step, the state of the transform code had become messy. I have renamed the onix.py to onix_utils.py and its purpose is to store functions relating to the handling of metadata for the telescopes. I have also moved many of the functions that were in oapen_metadata_telescope.py to this file.
To deal with the growing transform steps for oapen metadata, I have created the OnixTransformer class (in onix_utils). This class has only a single function made for use - the transform function. When called, this will execute the transform stage based on the configuration of the class instantiated during object initialisation. This class can also be used for the other ONIX transform steps (onix_telescope.py and thoth.py). I have not implemented this change as the scope of this PR is already quite extensive, but it would be good to make use of it in future.