To mark Crossref’s 25th anniversary, we launched our first Metadata Awards to highlight members with the best metadata practices.
GigaScience Press, based in Hong Kong, was the leader among small publishers, defined as organisations with less than USD 1 million in publishing revenue or expenses. We spoke with Scott Edmunds, Ph.D., Editor-in-Chief at GigaScience Press, about how discoverability drives their high metadata standards.
What motivates your organisation/team to work towards high-quality metadata? What objectives does it support for your organisation?
Our objective is to communicate science openly and collaboratively, without barriers, to solve problems in a data- and evidence-driven manner through Open Science publishing. High-quality metadata helps us address these objectives by improving the discoverability, transparency, and provenance of the work we publish. It is an integral part of the FAIR principles and UNESCO Open Science Recommendation, playing a role in increasing the accessibility of research for both humans and machines. As one of the authors of the FAIR principles paper and an advisor of the Make Data Count project, I’ve also personally been very conscious to practice what I preach.
On behalf of the Nominating Committee, I’m pleased to share the slate of candidates for the 2025 board election.
Each year we do an open call for board interest. This year, the Nominating Committee received 51 submissions from members worldwide to fill five open board seats.
We have four large member seats and one small member seat open for election in 2025. We maintain a balanced board of 8 large member seats and 8 small member seats. Size is determined based on the organization’s membership tier (small members fall in the $0-$1,650 tiers and large members in the $3,900 - $50,000 tiers).
In 2022, we wrote a blog post “Rethinking staff travel, meetings, and events” outlining our new approach to staff travel, meetings, and events with the goal of not going back to ‘normal’ after the pandemic and said that in the future we would report on our efforts to balance online and virtual events, work life balance for staff, and track our carbon emissions. In December 2024, we wrote a blog post, “Summary of the environmental impact of Crossref,” that gave an overview of 2023 and provided the first report on our carbon emissions. Our report on 2023 only just made it into 2024, so we are happy to report on 2024 a little sooner in the year.
To date, there are about 100 Crossref members who have made use of our co-access service for one or more of their books. The service was designed to be a last-resort measure when multiple parties - book publishers, aggregators, and other members - had rights to register book content. Unfortunately, the service allowed members to register multiple DOIs for shared books and book chapters, thereby violating our own core tenet of one DOI per content item. We should not have created a service that violated that tenet, resulting in duplicate DOIs. As we are able to offer an alternative in the form of the multiple resolution service, it is time to switch co-access off. Among other benefits – for the publisher and the authors, creation of a single DOI for each item, regardless of where it might be hosted, will result in more accurate citation counts and usage statistics. We’re retiring co-access at the end of 2026.
Funders can be represented three ways: 1) the ROR id, 2) the funder name, or 3) the funder name nested with the funder identifier. Since the Open Funder Registry is transitioning into ROR, using the ROR id to identify funders is the preferred method.
If you are not using a ROR id, funding metadata must include the name of the funding organisation and the funder identifier (where the funding organisation is listed in the Registry), and should include an award/grant number or grant identifier. Funder names should only be deposited without the accompanying ID if the funder is not found in the Registry. While members can deposit the funder name without the identifier, those records will not be considered valid until such a time as the funder is added to the database and they are redeposited (updated) with an ID. What that means is that they will not be found using the filters on funding information that we support via our REST API, or show up in our Open Funder Registry search.
Correct nesting of funder names and identifiers is essential as it significantly impacts how funders, funder identifiers, and award numbers are related to each other. If you use the ROR id to identify funders, this nesting is not neccessary and invalid.
Here are some examples in order of most to least preferred:
Correct: In this example, funder “National Science Foundation” is associated with the ROR id https://ror.org/021nxhr62. No name should be added.
Incorrect: Here, the funder name and ROR id are nested - this is invalid.
<fr:assertion name="funder_name">National Science Foundation
<fr:assertion name="ror">https://ror.org/021nxhr62</fr:assertion>
</assertion>
The purpose of funder groups is to establish relationships between funders and award numbers. A funder group assertion should only be used to associate funder names and identifiers with award numbers when multiple funders are present.
Funding data deposit with one group of funders (no “fundgroup” needed):
Funding data deposit with two fundgroups:
Incorrect: Groups used to associate funder names with funder identifiers, these need to be nested as described above.
Deposits using a funder_identifier that is not taken from the Open Funder Registry will be rejected.
Deposits with only funder_name (no funder_identifier) will not appear in funder search results in Open Funder Registry search or the REST API.
Deposits with award numbers or program years included in the funder_name will be processed with the funding data portion skipped and omitted. Please include the funder’s organisation name only.
The <fr:program> element in the deposit schema section (see documentation) supports the import of the fundref.xsd schema (see documentation). The fundref namespace (xmlns:fr=https://www-crossref-org.turing.library.northwestern.edu/fundref.xsd) must be included in the schema declaration, for example:
The fundref.xsd consists of a series of nested <fr:assertion> tags with enumerated name attributes. The name attributes are:
fundgroup: used to group a funder and its associated award number(s) for items with multiple funders.
ror: identifier of the funding agency as it appears in the Research Organisation Registry (ROR). To be used instead of nested funder_name and funder_identifier.
funder_name: name of the funding agency as it appears in the funding Registry. Funder names that do not match those in the registry will be accepted to cover instances where the funding organisation is not listed.
funder_identifier: funding agency identifier in the form of a DOI, must be nested within the funder_name assertion. The funder_identifier must be taken from the funding Registry and cannot be created by the member. Deposits without funder_identifier or ror do not qualify as funding records.
award_number: grant number or other fund identifier
Either rororfunder_name and funder_identifier must be present in a deposit where the funding body is listed in the Open Funder Registry. Multiple funder_name, funder_identifier, and award_number assertions may be included.
<fr:program name="fundref">
<fr:assertion name="funder_name">National Institute on Drug Abuse
<fr:assertion name="funder_identifier">https://doi-org.turing.library.northwestern.edu/10.13039/100000026</fr:assertion>
</fr:assertion>
<fr:assertion name="award_number">JQY0937263</fr:assertion>
</fr:program>
If multiple funder and award combinations exist, each combination should be deposited within a fundgroup to ensure that the award number is associated with the appropriate funder(s). In this example, two funding groups exist:
Funder National Science Foundation with ROR id https://ror.org/021nxhr62 is associated with award numbers CBET-106 and CBET-106, and
<fr:program name="fundref">
<fr:assertion name="fundgroup">
<fr:assertion name="ror">https://ror.org/021nxhr62</fr:assertion>
<fr:assertion name="award_number">CBET-106</fr:assertion>
<fr:assertion name="award_number">CBET-7259</fr:assertion>
</fr:assertion>
<fr:assertion name="fundgroup">
<fr:assertion name="funder_name">Basic Energy Sciences, Office of Science, U.S. Department of Energy
<fr:assertion name="funder_identifier">https://doi-org.turing.library.northwestern.edu/10.13039/100006151</fr:assertion>
</fr:assertion>
<fr:assertion name="award_number">1245-ABDS</fr:assertion>
</fr:assertion>
</fr:program>
Items with multiple funder names but no award numbers may be deposited without a fundgroup.
At a minimum, a funding data deposit must contain either a roror a funder_name and funder_identifier assertion, and using the ROR id is preferred. Deposits with just an award_number assertion are not allowed. A ror or nested funder_name\funder_identifierandaward_number should be included in deposits whenever possible. If a ROR id is used, it should not include a funder_name or funder_identifier.
If the funder name cannot be matched in ROR or the Open Funder Registry, you may submit funder_name only, and the funding body will be reviewed and considered for addition to the official Registry. Until it is added to the Registry, the deposit will not be considered a valid funding record and will not appear in funding search or the REST API.
As demonstrated in Example 3 below, items with several award numbers associated with a single funding organisation should be grouped together by enclosing the funder_name, funder_identifier, and award_number(s) within a fundgroup assertion.
Some rules will be enforced by the deposit logic, including:
Nesting of the<fr:assertion>elements: the schema allows infinite nesting of the assertion element to accommodate nesting of an element within itself. Deposit code will only allow 3 levels of nesting (with attribute values of fundgroup, funder_name, and funder_identifier)
Values of different<fr:assertion>elements: funder_name, funder_identifier, and award_number may have deposit rules imposed
Only valid funder identifiers will be accepted: the funder_identifier value will be compared against the Open Funder Registry file. If the funder_identifier is not found, the deposit will be rejected.
If funding metadata is incorrect or out-of-date, it may be updated by redepositing the metadata. Be sure to redeposit all available metadata for an item, not just the elements being updated. A DOI may be updated without resubmitting funding metadata, as previously deposited funding metadata will remain associated with the DOI.
Funding metadata may be deleted by redepositing an item with an empty <fr:program name="fundref"> element:
The <fr:program> element captures funding data. It should be placed before the <doi_data> element. This deposit contains minimal funding data - one ror must be present; it is recommended over using funder_name and funder_identifier.
This example contains one funder_name and one funder_identifier. Note that the funder_identifier is nested within the funder_name assertion, establishing https://doi-org.turing.library.northwestern.edu/10.13039.100000001 as the funder identifier for funder name National Science Foundation. Two award numbers are present.
This example contains one ror (for the National Science Foundation) and one funder_name/identifier (for Basic Energy Sciences, Office of Science, U.S. Department of Energy) with two award_numbers for each funder. Each funding organisation is within its own fundgroup.
<fr:program name="fundref">
<fr:assertion name="fundgroup">
<fr:assertion name="ror">https://ror.org/021nxhr62</fr:assertion>
<fr:assertion name="award_number">CBET-106</fr:assertion>
<fr:assertion name="award_number">CBET-7259</fr:assertion>
</fr:assertion>
<fr:assertion name="fundgroup">
<fr:assertion name="funder_name">Basic Energy Sciences, Office of Science, U.S. Department of Energy
<fr:assertion name="funder_identifier">https://doi-org.turing.library.northwestern.edu/10.13039/100006151</fr:assertion>
</fr:assertion>
<fr:assertion name="award_number">1245-ABDS</fr:assertion>
<fr:assertion name="award_number">98562-POIUB</fr:assertion>
</fr:assertion>
</fr:program>
Page maintainer: Riley Marsh Last updated: 2025-April-21
