ROSES Open Science and Data Management Plan
New in ROSES-2023: The requirements regarding archiving of data, software, and publications have been strengthened. In particular: 1) Publications (or as-accepted manuscripts) that derive from ROSES-2023 awards must be publicly available at the time of publication 2) Data and software developed using ROSES funding in support of a peer-reviewed publication shall be made publicly available at the time of publication, 3) Scientifically useful data and software developed during the award that was not already published must be made available by the end of the award, and 4) To be eligible to receive funding, PIs and Co-Is must provide their digital persistent identifier (e.g., ORCID) via NSPIRES under Account Management -> Personal Profile.
This page applies to ROSES-2023, not to ROSES-2022. Since ROSES-2022 and -2023 overlap early in calendar year 2023 both this page and the old ROSES DMP page will be visible at the same time, this covering ROSES-2023 and the old ROSES DMP page applying to ROSES-2022. Once ROSES-2022 closes, that page will be retired.
In keeping with the NASA Plan for Increasing Access to Results of Federally Funded Research the SMD Strategy for Data Management and Computing for Ground Breaking Science 2019-2024, and SPD-41A, SMD's Scientific Information Policy, which was updated late in 2022, most proposers to ROSES-2023 must provide an "Open Science and Data Management Plan", (formerly called the Data Management Plan) or an explanation of why one is not necessary given the nature of the work proposed. This Open Science and Data Management Plan (OSDMP) must address how publications, data, and software will be made available, see below.
The budget for the proposal should include any costs needed to implement the OSDMP.
If an OSDMP is required, it will be evaluated as part of the proposal’s intrinsic merit and thus will have a bearing on whether the proposal is selected. Unless otherwise stated in a program element, the OSDMP will be placed in a 2-page section in the proposal PDF immediately following the references and citations for the Scientific/Technical/Management (S/T/M) section of the proposal and does not count against the page limit for the S/T/M Section.
Program elements that do not conform to the default approach for OSDMPs described here will say so explicitly and they are: First, for some proposals the nature of the work is inexorably linked to the handling of data, so the OSDMP is part of the page-limited S/T/M section of the proposal. Examples include (but are not necessarily limited to) proposals to: B.7 Space Weather Science Applications, B.12 Heliophysics Data Environment Emphasis, C.4 Planetary Data Archiving, Restoration, and Tools, F.3 Exoplanets Research, and certain proposals to D.2 Astrophysics Data Analysis. Second, instrument development and technology development programs are generally exempted from providing an OSDMP under the presumption that no "data" will be generated. However, even if an OSDMP is not a required part of a proposal, if an award is made the standard obligations regarding release data, software and publications still apply, see below. Please also note that for instrument/technology development programs there is a requirement that applies only to them: final reports (only, not annual progress reports) must be made public via NASA TechPort.
As always with ROSES, the Summary of Solicitation sets the defaults, but any division may modify or supersede these in the Division Research Program Overviews (e.g., A.1, B.1…) or in a specific program element. For example, some elements (e.g., A.10 Sea Level Change Science Team) may require and allocate more space for a separate Software Development Plan and/or may require that software must be made publicly available under a certain kind of license, may specify preferred archives, or may otherwise require more than is outlined in the Summary of Solicitation and this FAQ. Some program elements provide templates for OSDMP. The template for the program elements in Appendix A (Earth Science) may be found here, the template for the program elements in Appendix B (Heliophysics) may be found here the template for the program elements in Appendix C (Planetary Science) may be found here and the template for the program elements in Appendix E (Biological and Physical Sciences) may be found here. Please read the program elements carefully.
Proposals should allocate suitable time and resources for making available these important results of federally funded research. For information about data rights and other aspects of intellectual property such as invention rights resulting from awards, see Appendix J of the NASA Guidebook for Proposers.
The archiving of data, software, and manuscripts must be addressed the annual progress reports. Not appropriately archiving these important results of ROSES-funded research may delay or prevent awarding of funds.
For the convenience of proposers, we address separately below data, software, and publications that result from ROSES awards.
Data needed to validate the scientific conclusions of a peer-reviewed publication resulting from an award, e.g., data underlying figures, maps, and tables in a publication must be made available at the time of publication. The remaining scientifically useful data must be made available at the end of the award, consistent with the OSDMP. Made available means publicly and electronically in a place where it can be found and it is likely to persist, e.g., in the supplemental material of the article, a community-endorsed repository, a NASA repository such as http://data.nasa.gov/, or a repository supported by a division, or a combination of different resources as would be most appropriate to the data being shared. When shared, the data must include robust metadata and be made available for access, download, or export in non-proprietary, modifiable, open, and machine-readable formats consistent with standards used in the disciplines. Publicly shared data must receive a persistent identifier, such as a Digital Object Identifier, to support citation. The data should be released with an open license such as Creative Commons Zero. Any limitations to the sharing of data should be described as part of the OSDMP. "Data" does not include laboratory notebooks, preliminary analyses, private communications, or certain other types of information that have been excluded from the definition in SPD-41a. In the case of a project that would produce no "data", or only data specifically exempted, the OSDMP must state that no data preservation or data sharing is needed and explain why. In a case where no appropriate archive exists for a particular data set, the OSDMP must discuss alternative methods for making the data publicly available.
The data section of the OSDMP must contain the following elements, as appropriate to the project, in adequate detail for review:
- A description of data types, volume, formats, and (where relevant) standards;
- A description of the schedule for data archiving and sharing;
- A description of the intended repositories for archived data, including mechanisms for public access and distribution;
- A discussion of how the plan enables long-term preservation of data;
- A discussion of roles and responsibilities of team members in accomplishing the OSDMP. If funds are required for data management activities, these should be covered in the normal budget and budget justification sections of the proposal.
Software needed to validate the scientific conclusions of a peer-reviewed publication resulting from an award, e.g., data underlying figures, maps, and tables in a publication must be made available at the time of publication. Starting with awards that result from ROSES-2023, the remaining scientifically useful software must be made available at the end of the award, consistent with the OSDMP. Software packages developed under the grant must be reported to https://invention.nasa.gov. Publicly available software projects developed under the grant must include a code of conduct and guidelines for contributors and when released, have a digital persistent identifier, such as a Digital Object Identifier, associated with it to support citation.
Software should be released with an open, permissive license such as Apache 2.0, BSD 3-Clause “Revised” License, or MIT License. Any limitations to sharing the software should be described as part of the SMP. More information on types of scientific software and how they should be shared is available in Appendix F of SPD-41a.
Starting with awards that result from ROSES-2023, the as accepted manuscript or the version of record of peer-reviewed publications must be made publicly available at the time of publication. There are two options for how to comply with this requirement: Either (1) the manuscript is individually uploaded to NASA PubSpace by the time of publication or (2) It is published in a journal that makes it openly available at the time of publication and also it is indexed by either CHORUS or ADS. For more information about meeting the requirements see "How to Share Publications" below. SMD encourages publications to be published Open Access, and any cost to do so may be included in the budget. SMD also encourages publications to be posted on community appropriate preprint servers.
How to Share Publications
For articles that are published as Open Access (see Open Access Publishing), the final published article (i.e., the publisher’s version of record) may be made publicly available in the STI Repository:
- For articles published as Open Access by journal publishers participating in the Clearinghouse for the Open Research of the United States (CHORUS), the published article will be made publicly available in the STI Repository on behalf of the authors. Authors should verify that their article is available in the STI Repository following its publication, in which case no further action is required by the author. View a list of journal publishers participating in CHORUS.
- For articles published as Open Access that are indexed in the NASA Astrophysics Data System (ADS), no further action is required by the researcher to comply with public access requirements for the article at this time.
- For articles published as Open Access that are not covered by CHORUS or ADS, authors must submit either the final published article or the author’s copy of an accepted manuscript to the NASA STI Repository via the PubSpace submission page no later than the article’s publication date.
For an article that is not open access, someone must submit at least the accepted manuscript* version to the NASA STI Repository via the PubSpace submission page no later than the article’s publication date. In some cases, archiving without embargo may be done for you by the journal but, in most cases, it must be done by the author. Look on the website of the journal for information about whether they will archive in NASA Pubspace at the time of publication or ask your journal editor. Ultimately, it is on the author to determine what they must do to make at least the manuscript version publicly accessible at the time of publication.
* The accepted manuscript is the final, peer-reviewed version of the article that has been accepted for publication by a publisher. The accepted manuscript includes all changes made during the peer review process and contains the same content as the final published article, but it does not include the publisher’s copyediting, stylistic, or formatting edits that will appear in the final journal publication (i.e., the version of record).
If you are proposing to Earth Science (appendix A of ROSES) then you will probably be using one of the DAACs which can be found via https://earthdata.nasa.gov/. Each DAAC has its own point of contact.
If you are proposing to Heliophysics (appendix B of ROSES) then you will probably be using one of the following archives:
Space Physics Data Facility https://spdf.gsfc.nasa.gov/submitting_data.html (POC Robert M. Candey: email@example.com)
Solar Data Analysis Center https://docs.virtualsolar.org/wiki/NewDataProvider (POC Jack Ireland: firstname.lastname@example.org)
For information about metadata, the relevant HP standard is the SPASE Data Model (see http://www.spase-group.org) which is used to populate a 'git' registry whose main public face is the Heliophysics Data Portal (https://heliophysicsdata.gsfc.nasa.gov). The required elements of the Data Model are the 'header' information that includes the Resource Type, Measurement Type, people, access URL(s), duration information and the like. More detailed description including the parameters (variables) in the data files are desirable but not required. Our SPASE group is prepared to help anyone with writing SPASE descriptions, and we hope to soon have an online tool for doing this.
If you are proposing to Planetary Science (appendix C of ROSES) then you will probably be using the Planetary Data System https://pds.nasa.gov/ Each node has its own point of contact.
If you are proposing to Astrophysics (appendix D of ROSES) then you may be using one of the archives at http://science.nasa.gov/astrophysics/astrophysics-data-centers/
If you are proposing to Biological or Physical Sciences (BPS Appendix E of ROSES) the BPS ROSES program element will specify to which database researchers should address in their DMPs but there are a few possibilities:
Space Biology has the Genelab (https://genelab.nasa.gov) database for omics-related experimental results and the Life Sciences Data Archive, shared with the Human Research Program, (https://lsda.jsc.nasa.gov) for experimental samples and other traditional results. Physical Sciences has the Physical Sciences Informatics database (https://www.nasa.gov/PSI).
Questions and Answers
Q1: “The new rules require that unpublished “useful” data and software be made available by the end of the award. What is “useful”?
A1: That will be determined by peer review. Please propose in your OSDMP and your peers will assess. But here’s a hint, if you referenced it in a talk (e.g., "I wrote a script to identify potential candidate locations…” then make it available.
Q2: I’m writing software in IDL, a proprietary language, is it OK to archive as it is? I could make IDL code available as a compiled code or runtime code which could be run without paying the license fee that one must pay to write in IDL.
A2: Even if it’s in a proprietary language, if its stand-alone software developed under a ROSES-23 grant you must archive the code. The compiled code or runtime code alone is not adequate.
Q3: Must I provide support for software, keep it updated?
A3: No, support is not required, nor must you provide updates after the completion of the grant. However, if you update the software thanks to subsequent SMD grants, you must archive the updated version.
Q4: What happens if the place software (or data) is hosted goes away? Must we be able to show that it will be available for 25 years, or whatever?
A4: It must be archived in a place where it will persist. If you are not using one of the “Preferred Archives” listed above, then the adequacy of the archive you suggest in your OSDMP will be assessed by peer review. Unless specified in the solicitation, there is no specific duration required.
Q5: The software is a mix of stuff I wrote, stuff my collaborators from 15 years ago wrote, and third-party stuff I found online on a site that’s now defunct as the developer retired/died. How do I release this if it doesn’t all belong to me?
A5: In such complicated cases like enhancements to existing proprietary software the requirement to make them available is merely "should" not must.
Q6: I’d like to make this software widely available in a language that is not proprietary, but I just don’t have time.
A6: One may request funding from F.8 Supplemental Open-Source Software Awards for converting to a not proprietary language like python.