Add support for reference publications

[rebeccaringuette]

What is the problem that your suggestion solves?

It is a common practice for software, data, instruments and other objects that are often indicated with DOIs to have reference publications. The strong desire of the authors of those items is that the reference publication be cited, but for the needs of transparency, a version-specific reference to the item (e.g. the software) is also required. However, there is no support for indicating that a reference publication should be cited with the item in the DataCite metadata. Due to the immense pressure from the community on this topic, we will likely not be able to mint DOIs for missions and potentially instruments until this feature is incorporated.

What solution might meet your needs?

Adding a relationType="CiteWith" would be a great solution. This addition could then also be reflected in citation generators (e.g. citation.doi.org) to generate a citation for both objects.

Your name

Rebecca Ringuette

Your organization

NASA SMD's Heliophysics Digital Resource Library

What alternatives have you tried or considered?

AlternativeIdentifiers is close, but the software/data/instrument/etc is not the same type of item as a publication, so this didn't work.

Is there anything else you would like to share?

NASA's SPD-41a states in section IV that "SMD shall provide a persistent identifier for all funding mechanisms and missions."
CodeMeta also includes a custom referencePublication field to support this need for software, but no mapping to DataCite is possible.

What group(s) would benefit from your suggestion?

• DataCite members registering DOIs and metadata and administering accounts
• Developers building integrations with DataCite services
• Harvesters who index DataCite DOIs and metadata
• Individuals or institutions analyzing DataCite DOIs and metadata
• DataCite staff
• Other

If other group(s), please describe.

No response

[rebeccaringuette]

@dgarijo

[dgarijo]

Thanks @rebeccaringuette. I think this is a common practice for software that we are missing. For example, in CFF files we see: message: "If you use this software, please cite both the article from preferred-citation and the software itself.". However, in the citation generated by the CFF file, only a single artifact appears. Ideally we would cite BOTH the zenodo doi for the version and the reference publication (if exists). Example of a CFF file that includes both artifacts: https://github.com/dgarijo/Widoco/blob/master/CITATION.cff
Example of what GitHub shows as citation (only the reference paper)

@article{Garijo_WIDOCO_A_wizard_2017,
author = {Garijo, Daniel},
doi = {10.1007/978-3-319-68204-4\_9},
title = {{WIDOCO: A wizard for documenting ontologies}},
year = {2017}
}

[KellyStathis]

Thanks for this suggestion, @rebeccaringuette!

Is the idea here to indicate that the resources linked by "citeWith" should always be cited together?

I was also wondering if you could point me to an example of a "reference publication" to help me understand this use case better. I'm familiar with data papers, if that's similar?

[rebeccaringuette]

Sure. Sunpy is a nice example. There are over 100 authors on the most recent version of the software, but only the original ~20 authors receive credit when the reference paper is cited.
version-specific software DOI: https://doi.org/10.5281/zenodo.17162925
reference paper: http://doi.org/10.3847/1538-4357/ab4f7a

The idea is to have the citation generated by doi.org to auto-include the reference paper when a software DOI is used, but this kind of auto-generation is only possible if a new relation type is implemented. Otherwise, all sorts of chaos would result if this were attempted because the existing relation types are used to indicate many more things than the reference paper. For example, if the software metadata has the "CiteWith" relation type,

{
  "id": "https://doi.org/10.5281/zenodo.17162925",
  "doi": "10.5281/ZENODO.17162925",
...
  "relatedIdentifiers": [
    {
      "relationType": "CiteWith",
      "relatedIdentifier": "http://doi.org/10.3847/1538-4357/ab4f7a",
      "resourceTypeGeneral": "JournalArticle",
      "relatedIdentifierType": "DOI",
    },
...
  ],
  "schemaVersion": "http://datacite.org/schema/kernel-4",
  "providerId": "cern",
  "clientId": "cern.zenodo",
  "agency": "datacite",
  "state": "findable"
}

Then the citation automatically generated would have the citation for the software AND the citation for the reference paper in the same output:

@SOFTWARE{sunpy_community2025,
  doi = {10.5281/ZENODO.17162925},
  url = {https://zenodo.org/doi/10.5281/zenodo.17162925},
  author = {Stuart J. Mumford,  and Nabil Freij,  and David Stansby,  and Steven Christe,  and Albert Y. Shih,  and Jack Ireland, ...(shortened for brevity) and Sophie A. Murray, },
  title = {sunpy: A Core Package for Solar Physics},
  publisher = {Zenodo},
  year = {2025},
  copyright = {BSD 2-Clause "Simplified" License}
}
@ARTICLE{sunpy_community2020,
  doi = {10.3847/1538-4357/ab4f7a},
  url = {https://iopscience.iop.org/article/10.3847/1538-4357/ab4f7a},
  author = {{The SunPy Community} and Barnes, Will T. and Bobra, Monica G. and Christe, Steven D. and Freij, Nabil and Hayes, Laura A. and Ireland, Jack and Mumford, Stuart and Perez-Suarez, David and Ryan, Daniel F. and Shih, Albert Y. and Chanda, Prateek and Glogowski, Kolja and Hewett, Russell and Hughitt, V. Keith and Hill, Andrew and Hiware, Kaustubh and Inglis, Andrew and Kirk, Michael S. F. and Konge, Sudarshan and Mason, James Paul and Maloney, Shane Anthony and Murray, Sophie A. and Panda, Asish and Park, Jongyeob and Pereira, Tiago M. D. and Reardon, Kevin and Savage, Sabrina and Sipőcz, Brigitta M. and Stansby, David and Jain, Yash and Taylor, Garrison and Yadav, Tannmay and Rajul and Dang, Trung Kien},
  title = {The SunPy Project: Open Source Development and Status of the Version 1.0 Core Package},
  journal = {The Astrophysical Journal},
  volume = {890},
  issue = {1},
  pages = {68-},
  publisher = {American Astronomical Society},
  year = {2020}
}

If a user instead wants to generate a citation to the reference publication, some sort of reverse mechanism would be ideal. When the citation to the reference publication is generated from a request based on the publication DOI, it would help to have the software citation pop up as a suggestion. This "reverse" workflow needs a bit of workshopping to figure out the right path.

[rebeccaringuette]

@KellyStathis Is there any way to get this relation type into the next version (4.7) of DataCite? The drafts for the needed pieces are below:
"CiteWith"
Definition: indicates that A is to be cited with B
Example and Usage Notes: The envisioned example is to indicate the registered resource is to be cited whenever resource B is cited in alignment with longstanding FORCE11 recommendations, such as when B is the reference publication for A. The publication of reference publications is common for instrument, datasets, software, and other similar resources.

<relatedIdentifier relatedIdentifierType="DOI" relationType="CiteWith" resourceTypeGeneral="JournalArticle">10.3847/1538-4357/ab4f7a</relatedIdentifier>

[rebeccaringuette]

@mbjones This is also relevant for datasets. What are your thoughts here?

[KellyStathis]

@rebeccaringuette The Metadata Working Group discussed this suggestion earlier this month. There were a few themes from that discussion:

• Our recommendation is to use the existing relationTypes (most likely IsDocumentedBy or IsDescribedBy) to link software to a reference publication. If needed, you can also add more context with the attribute relationTypeInformation (which was added in 4.7).
• The Metadata WG also discussed your suggestion to update the citation generation logic to generate multiple citation strings from one DOI upon certain conditions (like if a relationType="citeWith" is present), and were concerned that this would add complexity and user confusion if we were to deviate from the one DOI -> one formatted citation approach. It is important that software can be cited independently, even if there is a reference publication.

For linking reference publications to software in DataCite DOI metadata records, have you looked into using these relationTypes and the new relationTypeInformation attribute?

For citation generation, do you have any more context on your process? Do you use any additional tools beyond citation.doi.org?

Let us know if you have any questions or followup thoughts! I've shared this suggestion post with the Metadata WG to follow any additional discussion.

[rebeccaringuette]

Thanks for the feedback, Kelly. I completely agree that the two existing relation types mentioned are appropriate for publications describing data, software, and other technical items, including reference publications, but the problem remains of how to distinguish in the metadata between the official reference publication and these other descriptive works. The critical difference between them being that the software / data contributors have designated that (typically) one publication for their users to formally cite so that those citations positively reflect in their performance reviews and proposal reviews. This is because citations to the software/data/etc are unfortunately not typically considered.
Based on interactions with software developers and the performance and funding comments already made, I must respectfully disagree that software should be cited independently of these reference publications. Yes, it should absolutely be cited when used, but the data/software/etc contributors receive no benefit unless the reference publication is also cited. Please allow me to advocate for them by requesting that the group reconsider this issue.
One way this could be done is to encourage the use of "Other" with the new "relationTypeInformation" = "ReferencePublication" and then to incorporate this into the citation.doi.org service. However, it is not a good approach to use a free text field as something to base logic on. A standard relation type would be a much more dependable choice, especially with something as important as proper citation generation. An example citation produced could look something like the example below when a software DOI is entered into the citation.doi.org service. We are about to do user testing on this in the next few days to get feedback.
Software
MacBride, C. D., & Jess, D. B. (2023). MCALF: Multi-Component Atmospheric Line Fitting (Version v1.0.0) [Computer software]. Zenodo. https://doi.org/10.5281/ZENODO.3924527
Reference Publication
MacBride, C., & Jess, D. (2021). MCALF: Multi-Component Atmospheric Line Fitting. Journal of Open Source Software, 6(61), 3265. https://doi.org/10.21105/joss.03265

[dorothearrr]

I understand the underlying problem, but I would oppose trying to solve it through DOI metadata.
Making data and software citable as independent resource outputs is part of DataCite’s mission. I fear that auto-generating citations to specific research articles could run counter to that.
I also see a risk of misuse with the auto-generation of citations — this approach could, for example, be used to artificially inflate citations to research articles without a connection to software or research data.
In my opinion, the problem would be addressed more effectively by changing the evaluation procedures rather than by changing the DOI metadata.

[dgarijo]

Sorry, I don't understand this point.
@rebeccaringuette's point (if I understand it correctly) is not to autogenerate citations. It's to acknowledge that both software and papers may be reference publications for a software at the same time. At the moment people may lean on their reference publications directly. But metadata schemas don't allow representing "when you want to refer to this software, cite both the paper and the software deposit" (except for CFF)

[dorothearrr]

My understanding of the suggestion is that one of the goals is to enable auto-generation downstream. In certain contexts, this makes sense, but I see the potential for unintended consequences if it were implemented more widely (for example in the doi citation formatter).

[dgarijo]

More than auto generation, it's acknowledgement that both software and paper go in tandem. It's in the end what the authors want in many cases (e.g., when explicitly stated)

[rebeccaringuette]

Thanks for the conversation, and thanks for the support, @dgarijo.
I completely see your point, @dorothearrr. Supporting an auto-linking in the citation generation service could definitely be abused in the system if thoughtful guardrails are not put in place. Concerning your other comment, there have been notable efforts for many years to shift the evaluation priorities in this way (e.g., DORA), but culture shifts slowly. I expect the problem will remain for several years to come despite ongoing heroic efforts by many such organizations.
In the meantime, we are left with this problem. How can we promote citation of reference publications for technical artifacts to increase retention of technical staff at companies/institutions where performance is primarily judged by references to peer-reviewed publications? We need a way to uniquely identify the relationship between those technical artifacts (e.g., software, data, workflows, hardware, etc) and the reference publications without supporting citation inflation. The relationType suggestion "CiteWith" will need some limitations, possibly

• can only be applied to technical resource types, such as software, datasets, workflows, physical objects, and models. The linked resource type must be a text-type of object (e.g., JournalArticle).
• can only be used one time per object.

An alternative could be to use the DataPaper resource type if that could be expanded to cover these other technical resource types. If that were possible, the reference publication would need to be categorized as that resource type and then linked to the technical item with an existing relation type. The puzzle here would be how to assign more than one resource type to a given item, such as when the reference publication is a peer-reviewed journal article and publication policies prevent the minting of a separate DOI (and thus assigning a second resource type). My guess is there would still need to be similar guardrails in the system such as the two suggested above. The desired generated citation in the citation.doi.org service would still need include the citation to this paper in addition to the citation to the technical item when the DOI for the technical item is entered.
What do you think? Has my brainstorming triggered any other ideas?

[rebeccaringuette]

RO-Crate uses the "cite-as" relation type from IANA, which could be imitated here to achieve this purpose. https://datatracker.ietf.org/doc/html/rfc8574