Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix datacite renderer #117

Merged
merged 5 commits into from
Jan 5, 2023
Merged

Fix datacite renderer #117

merged 5 commits into from
Jan 5, 2023

Conversation

kimakan
Copy link
Contributor

@kimakan kimakan commented Dec 9, 2022

Fixes the datacite renderer in a way that make it compatible with https://schema.datacite.org/meta/kernel-4.4/doc/DataCite-MetadataKernel_v4.4.pdf

Some of the fixes are:

  • Subject has attributes that were present in metadata/settings but not rendered
  • Add name_type for creators and contributors
  • Overhaul of the licensing to fit the specifications of datacite
  • Add full support for affiliations

@coveralls
Copy link

coveralls commented Dec 9, 2022

Pull Request Test Coverage Report for Build 3689087086

  • 5 of 17 (29.41%) changed or added relevant lines in 3 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.04%) to 65.842%

Changes Missing Coverage Covered Lines Changed/Added Lines %
daiquiri/metadata/serializers/datacite.py 4 6 66.67%
daiquiri/core/renderers/datacite.py 0 10 0.0%
Files with Coverage Reduction New Missed Lines %
daiquiri/core/renderers/datacite.py 2 3.13%
Totals Coverage Status
Change from base Build 3619221320: -0.04%
Covered Lines: 4603
Relevant Lines: 6991

💛 - Coveralls

Copy link
Member

@agy-why agy-why left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes looks ok. But I guess they changes the metatda model, so we need to add the migration to this PR.

Did you test this on test machine already? For which instance?


if not name:
name = '{}, {}'.format(last_name, first_name)

self.node(person_type + 'Name', {}, name)
self.node(person_type + 'Name', {'nameType': name_type}, name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is nameType coming from? Is that just an additional field in the JSON entry for authors, contributors?

If yes then we should check fro missing values:

if name_type is not None:
    self.node(person_type + 'Name', {'nameType': name_type}, name)
else:
    self.node(person_type + 'Name', {}, name)

Except there is some kind of validation of the JSON fields before calling the render_person method? In which case we need to add a validation for name_type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name_type comes from

           name_type = person.get('name_type')

This returns None if name_type is not defined in metadata and it will not appear on the datacite rendered page. Just checked it again on my local machine.
An example (name_type is not defined for my name but for Joe Doe)

<creators>
  <creator>
    <creatorName nameType="Organizational">Leibniz Institute for Astrophysics Potsdam</creatorName>
  </creator>
  <creator>
    <creatorName>Makan, Kirill</creatorName>
    <givenName>Kirill</givenName>
    <familyName>Makan</familyName>
    <nameIdentifier nameIdentifierScheme="ORCID" schemeURI="http://orcid.org/">0000-0000-0000-0000</nameIdentifier>
    <affiliation affiliationIdentifier="https://ror.org/03mrbr458" affiliationIdentifierScheme="ROR" schemeURI="http://ror.org">Leibniz Institute for Astrophysics Potsdam</affiliation>
  </creator>
  <creator>
    <creatorName nameType="Personal">Doe, Joe</creatorName>
    <givenName>Joe</givenName>
    <familyName>Doe</familyName>
    <nameIdentifier nameIdentifierScheme="ORCID" schemeURI="http://orcid.org/">0000-0000-0000-0000</nameIdentifier>
  </creator>
  </creators>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok then all fine. Let us give a try and see how it renders on the registry side.

@kimakan
Copy link
Contributor Author

kimakan commented Dec 12, 2022

The fields creator, contributor and related_identifier are of the type JSONField in the model. Thus, no changes in the metadata model are required. I purposely tried to avoid such consequences.
I tested this version on my local instance and everything worked and rendered nicely. Also, these changes does not break anything from the previous metadata versions. The entries that are not defined will simply not rendered/left out.

@agy-why
Copy link
Member

agy-why commented Dec 12, 2022

I see, and since the licences identifiers are MethodsSerializers they do not require either changes in the model.

@agy-why
Copy link
Member

agy-why commented Dec 12, 2022

The entries that are not defined will simply not rendered/left out.

Although in this case the entry is defined: {'nameType': name_type}. But maybe you mean that defined entry with None value are not rendered, correct?

@kimakan
Copy link
Contributor Author

kimakan commented Dec 13, 2022

There is one additional change that I would like make. Currently, we provide only the Updated date explicitly. However, the datacite.org seems to use the mandatory PublicationYear we are providing to create the Issued date internally.
https://api.datacite.org/application/vnd.datacite.datacite+json/10.17876/gaia/dr.3

      "dates": [
        {
          "date": "2022-06-13",
          "dateType": "Updated"
        },
        {
          "date": "2022",
          "dateType": "Issued"
        }
      ],

This date follows the YYYY format which isn't precise.

I suggest that we provide the Issued date explicitly by using the published field from the metadata. We are already using it to create PublicationYear for the datacite.org but we drop MM-DD due to the requirements for PublicationYear.

@agy-why
Copy link
Member

agy-why commented Dec 13, 2022

@kimakan 👍

Issued: published full date YYYY-MM-DD
PublicationYear: published year only YYYY

@agy-why agy-why self-requested a review January 5, 2023 10:24
Copy link
Member

@agy-why agy-why left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok for me!

@agy-why agy-why merged commit 28382f6 into master Jan 5, 2023
@agy-why agy-why deleted the fix-datacite-renderer branch January 5, 2023 10:58
@agy-why agy-why added this to the version 0.4.1 milestone Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants