Suggestion: Investigate ways to resolve confusion about and reduce the maintenance burden of the "Datacite" and "OpenAIRE" metadata exports

[jggautier]

Overview of the Suggestion
Investigate ways to resolve confusion about and reduce the maintenance burden of the "OpenAIRE"/"oai_datacite" and "DataCite"/"Datacite" metadata exports. The closed GitHub issue that this issue replaces, at #5889, has the gist of it but its details are out of date after we made significant changes to the "Datacite" export.

What kind of user is the suggestion intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
All user roles

What inspired this idea?
Confusion about the two metadata exports (such as https://groups.google.com/g/dataverse-community/c/S8YaKcfyJbg/m/2iYmoBhzAQAJ) and the extra work involved in syncing the two exports, which may become more out of sync as the Dataverse community continues to change the metadata it sends to DataCite (such as the tasks described in IQSS/dataverse-pm#127).

What behavior do you want changed?
The investigation may lead to changes to the two metadata exports or a merging of the metadata exports into one, or letting Dataverse installation managers include or remove the OpenAIRE export, or other changes.

Tasks

Task	Due date
Review what's in both exports, following work @qqmyers did when he added more information to the "DataCite"/"Datacite" export. See the Differences between OpenAire export and new DataCite XML submitted to DataCite (Google Doc)	Dec 9, 2025
Try to follow up with OpenAIRE standard maintainers to understand their plans for it, which might influence how we resolve the confusion of the "OpenAIRE"/"oai_datacite" and "DataCite"/"Datacite" and reduce burden of maintaining both	Dec 10, 2025 - Feb 28, 2026
Follow up with Dataverse repository managers who who need OpenAIRE to harvest their metadata to make sure that their needs are accounted for if we make any changes that affect the OpenAIRE export	Mar 1, 2026 - Apr 30, 2026
Work with development team to determine next steps	?

Any open or closed issues related to this suggestion?

• Align or merge DataCite metadata exports #5889
• DataciteXML changes Plus RelationType field #10632
• Add import for oai_datacite ("OpenAire") format (this will allow Dataverse to harvest this format too) #7727

[jggautier]

I'm using a Google Sheet to describe the differences between the DataCite and OpenAIRE exports, following comparisons I and others discussed in the GitHub issue at #5889, in @qqmyers's comparison in a Google Doc, and exports I downloaded this week from Demo Dataverse, which is running Dataverse v6.9.

I don't mean to include all differences, and I'm describing the differences based on what I can see from the XML files I downloaded from test datasets on Demo Dataverse.

This comparison is also being influenced by my bias to remove the OpenAIRE export and to rename the "DataCite" export as oai_datacite for Dataverse's API calls and OAI-PMH, so that folks who manage Dataverse repositories that need to be harvested by OpenAIRE's systems can still tell the OpenAIRE systems to harvest the metadata of their published datasets using OAI PMH and the oai_datacite format. That is, for every difference I find I'm asking "Is this a reason to keep trying to maintain both exports? What do we need to learn about this difference and what changes might we need to make to remove the OpenAIRE export?"

Some remaining things I need to do are:

• understand the logic used to determine what Dataverse adds for the "date" elements in the Datacite and OpenAIRE exports, and what it adds in the Publication Year element, which Jim mentioned back in June 2024. The logic is pretty conditional.
• confirm with members of the Dataverse community who might know more or with folks at OpenAIRE if OpenAIRE's systems will be okay with harvesting XML records that point to DataCite's 4.5 schema instead of the 4.1 schema that Dataverse's OpenAIRE export uses now

So far, while the the comparison in the Google Sheet describes a few design decisions made for the OpenAIRE export that either we should consider adding to the DataCite export or that might be missing from the DataCite export because of bugs, like what's described in the recent pull request #12034, generally I think the DataCite export includes design decisions that seem better than decisions that community members made for the OpenAIRE export, often because those design decisions account for changes that we made to Dataverse after the OpenAIRE export was added to Dataverse (in v4.14 released in May 2019, #4257).

More importantly, so far I don't see any cases where our design decisions should be different for the two exports, it seems that having both exports has meant needing to make improvements to both, and there are cases where that hasn't happened. For example, however we decide the Publication Year should be determined, I don't think they should be determined one way in one export and another way in the other export. Both exports are based on DataCite's schema, and from what I understand from past discussions and from the OpenAIRE's guidelines at https://guidelines.readthedocs.io/en/latest/data/index.html and at https://guidelines.openaire.eu/en/latest/data/use_of_datacite.html, the differences between what the folks at OpenAIRE and DataCite want are about:

• What types of identifiers can be used for the resource. OpenAIRE allows repositories to use DataCite's identifierType to indicate any type of identifier that the repository uses to register the dataset, like the "Handle" in the identifierType of the OpenAIRE export of the dataset at https://hdl.handle.net/21.15109/ARP/BVJHD3. DataCite requires that repositories use only "DOI" for the identifierType.

  But in repositories running the latest versions of Dataverse, datasets that have Handles or other PIDs that aren't DOIs create DataCite exports where the identifierType is "Handle" or whatever type of identifier the dataset has, so this part of the DataCite export also follows OpenAIRE's guidelines.

• What types of dataset-level information they make mandatory versus optional, which managers of Dataverse repositories and collections can control regardless of how we design the exports

• The use of four mandatory Access Rights terms, which we include in both exports anyway, maybe since PR #10632 was merged as part of Dataverse v6.4

[jggautier]

In recent email conversation with @juancorr, he pointed to https://guidelines.openaire.eu/en/latest/data/use_of_datacite.html, which lists another difference between the DataCite schema and OpenAIRE's guidelines that I hadn't been considering: DataCite requires that in the identifier property, where their systems would expect to find the identifier of the resource, the identifierType should always be "DOI", like <identifier identifierType="DOI">21.15109/ARP/BVJHD3</identifier>,
while OpenAIRE's guidelines say that the identifierType can be whatever type of identifier the resource is, like <identifier identifierType="Handle">21.15109/ARP/BVJHD3</identifier>. I added this difference to my comment from last week.

However, when repository managers register Handles or other types of PIDs for their datasets, their "DataCite" exports still have DOI as the identifierType, like the DataCite export of the dataset at https://hdl.handle.net/21.15109/ARP/BVJHD3.

When managers of repositories using non-forked versions of the latest Dataverse versions register Handles or other types of PIDs for their datasets, the identifierType in their "DataCite" exports is "Handle" or whatever identifierType they're registering for their datasets.

[qqmyers]

FWIW: https://repo.researchdata.hu/, which houses dataset.xhtml?persistentId=hdl:21.15109/ARP/BVJHD3 is a fork from Dataverse ~v6.1 and doesn't represent current practice w.r.t. the DataCite export. Looking at the current code, the type can be DOI, Handle or URL (for PermaLinks) today. DataCIte only gets a copy if you are using DataCite DOIs so there's no problem with their APIs.

[jggautier]

Perfect, thanks Jim! I see this in other installations using later versions of Dataverse and using Handles, like the "Datacite" export of a dataset in MELDATA:
<identifier identifierType="Handle">20.500.11766.1/FK2/R8MUCH</identifier>

[jggautier]

One blocker to merging the "OpenAIRE" and "Datacite" exports has been not being sure if OpenAIRE's systems can use OAI-PMH to harvest XML that points to newer DataCite schema versions.

OpenAIRE's documentation says it adopted DataCite v3.1, but Dataverse's OpenAIRE export has always pointed to DataCite's v4.1 schema, so OpenAIRE's systems should be able to harvest XML that points to newer DataCite schema versions. So I think the blocker was more about confusion with the documentation.

I wrote in October 2025 that the next step would be to follow up with Dataverse installation managers who need OpenAIRE to harvest their metadata. To do this I'll post an update in the Dataverse Google Group, and may send emails directly to some installation managers, to give everyone until March 1 to bring up anything I might've missed and that we should consider about this plan to merge the two exports.

Then unless there are any surprises, I'm hoping that during sprint 19 we can do all the work needed to merge the two exports as part of the Dataverse release that's right after the v6.10 release.

[pdurbin]

If I'm reading https://groups.google.com/g/dataverse-community/c/7FXrKpP_suw/m/EhKSmNeWBgAJ and the above correctly when we are done the following Datacite exporter (highlighted in blue) will no longer be available via API:

That's fine but let's be sure to:

• Update the docs above to explain that oai_datacite should be used instead.
• Update the API breaking changes changelog (6.9 version) to call out this breaking change.
• Write this up in the release notes, like usual.