Problems with reporting funding with ROR

I’ve been attempting to report funding for journal articles using ROR. I understand that this is a new paradigm as crossref shifts from fundref to ROR, but the documentation is somewhat ambiguous on how to structure it. The particular example I supplied was within the <crossmark><custom_metadata> section and formatted as follows:

<fr:program name="fundref">
  <fr:assertion name="funder_name">Swiss National Science Foundation
   <fr:assertion name="funder_identifier">https://ror.org/00yjd3n13</fr:assertion>
  </fr:assertion>
  <fr:assertion name="award_number">192364</fr:assertion>
 </fr:program>

I have created this based on the instructions here for ROR and this page for instructions on how to format a single funder. Unfortunately it generates the following error:

<record_diagnostic status="Warning">
      <doi>10.62056/akp2fhbmo</doi>
      <msg>Funder identifier not found in Crossref: 13 
Fundref portion of deposit skipped</msg>
   </record_diagnostic>

This seems to imply that there is an error in parsing the ROR ID from the funder_identifier field. My question is - how do we actually use ROR as funding identifiers?

Hello, and thanks for your question.

The document you mentioned “Including ROR as a funder identifier in your metadata (metadata prototyping instructions)” was included in a blog post from January which was giving a progress update on the project to eventually support RORs in funding metadata.

This is all still very much in process. The document contains plans and prototyping for eventually testing, which all needs to happen before we update the metadata schema to support ROR IDs in that “funder_identifier” assertion. None of that has happened yet, which is why you’re getting an error indicating that the ROR ID isn’t supported.

So, basically the answer to “how do we actually use ROR as funding identifiers?” is that you can’t yet. We’re working on it, but it’s a big project and we don’t have a clearly defined time frame.

I’ll see about editing the document and blog post to make it clearer that they only pertain to work that’s in progress, planning for the future, and that it’s not documentation for an already-supported change.

Best,
Shayn