ROSES Open Science and Data Management Plan
Unless otherwise stated, proposals must include an Open Science and Data Management Plan (OSDMP), see below. The requirements regarding archiving of data, software, and publications were strengthened last year. In particular: 1) As-accepted manuscript versions of publications that derive from ROSES 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 publicly 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. See the section on "Persistent Identifiers for Investigators" in the SMD Open-Source Science Guidance at http://science.nasa.gov/oss-guidance. To support the sharing of scientific information, SMD will provide a Digital Objective Identifier (DOI) for the information released publicly for the award (title, abstract, and authors).
Unless otherwise stated, proposals must include an "Open Science and Data Management Plan" (OSDMP). This OSDMP must address how publications, data, and software will be made available, see below.
If program element requires an OSDMP, 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, the OSDMP must be placed in a two-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. See https://science.nasa.gov/researchers/sara/faqs/OSDMP and the SMD Open-Source Science Guidance at http://science.nasa.gov/oss-guidance.
For programs participating in Dual-Anonymous Peer Review, the OSDMP must be anonymized.
Program elements that do not conform to the default approach for OSDMPs described here will say so explicitly. For some proposals, the nature of the work is inexorably linked to the manipulation and processing of data, so the OSDMP is an integral part of the page-limited S/T/M section of the proposal. For example, D.2 Astrophysics Data Analysis places the OSDMP within the 15-page S/T/M section of the proposal. Additionally, 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 the release of data, software, and publications described here still apply.
As always with ROSES, this 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, see Section I(g) of the ROSES Summary of Solicitation. For example, some elements 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 license, may specify preferred archives, or may otherwise require more than is outlined in this Summary of Solicitation. Some program elements provide templates for the 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, and the template for the program elements in Appendix C (Planetary Science) may be found here. Please read the program elements carefully.
The OSDMP should explain the roles and responsibilities of team members in accomplishing the plan. Proposals should allocate suitable time and resources for making available these important results of federally funded research. If funds are required for information management activities, these should be covered in the normal budget and budget justification sections of the proposal. For information about data rights and other aspects of intellectual property such as invention rights resulting from awards, see Appendix I of the NASA Proposer’s Guide.
The archiving of data, software, and manuscripts must be addressed in the annual progress reports. Not appropriately archiving these important results of ROSES-funded research, as described below, may delay, or prevent annual increments of funds.
For the convenience of proposers, we address separately below data, software, and publications that result from ROSES awards.
(i) Data
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.
Any data needed to validate the scientific conclusions of peer-reviewed publications that result from an award must be made available at the time of publication; this includes data required to derive the findings communicated in figures, maps, and tables. 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 archived 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/, 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.
For more information about meeting these requirements, see 'Data Management and Sharing' in the SMD Open-Source Science Guidance. No later than 2025, SMD plans to provide additional options for the long-term hosting of data produced from SMD ROSES awards. This may include hosting at NASA or Federal data repositories, community-based repositories, or other instructions for how the data should be archived. Thus, researchers need not include the cost of public access to their data or storing their data beyond the end of the period of performance of their award in their budgets. Future guidance and instructions related to how to publicly share the data will be made available via the Scientific Information Policy website.
(ii) Software
Software needed to validate the conclusions of a peer-reviewed publication resulting from a ROSES award must be made available at the time of publication. Starting with awards that result from ROSES-2023, the remaining useful software must be made available at the end of the award, consistent with the OSDMP. Software packages developed under a federal assistance award 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 OSDMP.
For more information, see 'Software Management and Sharing' in the SMD Open-Source Science Guidance. The method of archiving software will not result in a weakness for proposals to ROSES-2024. No later than 2025, SMD plans to provide more options for the long-term archiving of software produced from SMD ROSES awards, in addition to those in the SMD Open-Source Science Guidance. Thus, researchers need not include the cost of public access to their software, maintaining their software, or storing their software beyond the end of the period of performance of their award in their budgets. Guidance on how to share software including providing a DOI is described in the SMD Open-Source Science Guidance at https://science.nasa.gov/oss-guidance. Future guidance and instructions related to how to publicly share software will be made available via the Scientific Information Policy website.
(iii) Publications
For awards that result from this ROSES, 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 may be individually uploaded to NASA PubSpace by the time of publication, or (2) it may be published in a journal that makes it openly available at the time of publication and is indexed by ADS, CHORUS, or NASA Science Explorer (scixplorer.org). For more information about meeting the requirements on published papers, see "How to Share Publications" at https://science.nasa.gov/researchers/sara/faqs/OSDMP, or in the SMD Open-Source Science Guidance at https://science.nasa.gov/oss-guidance. SMD encourages publications to be published Open Access, and any cost to do so may be included in the proposal budget. SMD also encourages publications to be posted on community appropriate preprint servers.
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).
Preferred Archives
If you are proposing to Earth Science (Appendix A of ROSES) then the DAACs may be an option for archiving the data. More info on the DAAC assignment process can be found at https://www.earthdata.nasa.gov/engage/data-management-guidance#daac. 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: robert.m.candey@nasa.gov)
Solar Data Analysis Center https://docs.virtualsolar.org/wiki/NewDataProvider (POC Jack Ireland: jack.ireland-1@nasa.gov)
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 you should refer to ROSES appendix C.1, Section 3.7.6 Acceptable Data Repositories.
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/
In addition to the archives given for planetary and Astrophysics above, there is also this exoplanet archive at https://exoplanetarchive.ipac.caltech.edu/docs/contribute_data.html While it’s true that much of their holdings are observational data, they also, for example, host synthetic data sets that are of value to the exoplanet community. If you are generating this kind of data and think that your audience might be more likely to find it there, engage them in a conversation with them to see if they want to host your data.
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 Open Science Data Repository (OSDR) https://osdr.nasa.gov/bio database for both omics-related experimental results (GeneLab),and the Ames Life Sciences Data Archive (ALSDA) for the phenotypic-related experiments and operational data related to life science missions.
- 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 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.
Please also see the Science Information Policy FAQs at https://science.nasa.gov/researchers/open-science/science-information-policy_faq/
Questions may be directed to SARA@nasa.gov
