The XML downloaded with the Datacite plugin does not comply with Datacite standards

Good morning, I’m referring to the Medra plugin issue on OJS 3.5.0-1 and 2. I’m reporting a standard issue with the generated XML file, which already occurs in all previous versions of OJS.

Can you please report this to the plugin developers?

The XML generated in version 3.4.0-8 (the last one that worked) didn’t extract all the fields correctly.

In practice, the downloaded XML, which in theory would have been automatically passed to Datacite for DOI submission, doesn’t have the ROR field in the field.

Here’s an example of what I added in creator:

Still in the creator field, I manually add the given fam-ily name.

Screenshot 2025-12-11 alle 09.46.33

The relatedItems field is missing:

Screenshot 2025-12-11 alle 09.46.58

The field alternateIdentifiers is completely unnecessary and could be deleted.

In the field, the DOI name after the 10.xxxx/ prefix is ​​incorrectly entered.

I’ve always had to enter it manually to comply with Datacite standards.

Can the plugin developers correct this?

Hi @simgiallorosso,

I see this is already cross-posted here:

https://github.com/pkp/medra/issues/63

Please just post an issue to one place to help reduce the clutter; if you do post twice, make sure to cross-link the resources.

Thanks,
Alec Smecher
Public Knowledge Project Team

Hi @simgiallorosso

Do you use ROR plugin for OJS?
If ROR plugin is used and an author has a ROR, it sould be considered in the DataCite XML export.
:thinking:
In 3.5 RORs are part of the core, and are considered in the export.

In 3.6 we will add support for different types of contributors, like person, organization and anonymous. There we will consider them also in DataCite XML export, and will then also givenName and familyName. See Consider new contributor types and roles for metadata distribution · Issue #12152 · pkp/pkp-lib · GitHub .

What do you exactly mean with DOI name incorrectly entered?

I made a not for myself to consider publisher and eventually remove alternateIdetifiers.

Thanks a lot!
Bozana

Yes, we use the ROR plugin. However, we’re still using OJS 3.4.0-8,
so we’re not benefiting from the improvements in version 3.5.

However, we’re afraid to update, given the problem with it not downloading the XML files via the Datacite plugin, as reported in my other post.

But I think version 3.6 is a long way from being released, right?
We’ll wait for further improvements.

By incorrect DOI, I mean, it exports it like this:

instead of

I don’t understand why it uses the volume “/jgsg.v3iSpecial Issue” as a reference instead of the article to complete the DOI “/jgsg-87”

Hi @simgiallorosso

Does your issue has such a DOI “10.jgsg.v3iSpecial Issue”?

If you use ROR plugin and the author has a ROR ID, it should be exported. Could you double check?

Thanks!
Bozana

This is the code that adds relation to the issue, for your OJS version 3.4.0.8: ojs/plugins/generic/datacite/filter/DataciteXmlFilter.php at 3_4_0-8 · pkp/ojs · GitHub.
Does it look the same in your installation?
Maybe you could try to debug it, to see how this “Speical Issue” comes there?

:thinking:

The code is the same

Could you then check what DOI is in your system for that issue “Vol 3 Special Issue”?
If you enabled DOIs for issues, you can see it on the DOIs management page, on the Issues tab.

The DOI used in that relatedItem element is from the issue the article belongs to, not from the article itself.

jgsg-v3special issue clearly takes that value from the volume where the article was published, but it’s a useless field.
It would be correct, instead of taking the volume field, to take the doi value assigned to the article.
Do I make myself clear?

That element describes relation of the article to the issue, so the issue DOI is used there, telling that the article isPartOf that issue (DOI)