Process and Criteria for RDA Recommendations

NB: This page has been revised in July 2018.

"RDA Recommendations" are the official endorsed results of RDA Working Groups. Recommendations undergo formal phases of discussion, comment, and decision making. RDA Recommendations are documents in a very broad sense and may include specifications, taxonomies or ontologies, workflows, schemas, data models, etc. They must, however, meet certain criteria to be adopted and endorsed as RDA outputs including being made publicly available and useable. RDA Recommendations are distinctly labeled as such and are maintained by the Secretariat in a specific repository.

This document describes the process and criteria for defining and endorsing RDA Recommendations. The document is maintainted by the Secretariat. It is subsidiary to the RDA Outputs Policy approved and maintained by the RDA Council. Both documents are supported by the RDA norms for contributing to and using RDA products which, as norms not policy, are intended to be maintained as a community document.

Process for Endorsing RDA Recommendations

1. Submission: The Chairs of a WG sens a document to the Secretariat as a draft version of a Recommendation. The draft Recommendation should include the following in a template to be provided by the Secretariat:
   • A brief description of the Recommendation's purpose and application
   • Requisite citation information including authorship
   • A plan for maintaining and retiring the Recommendation
   • A detailed justification for any variance from the default RDA Recommendation license or waiver
2. Initial Review: The Secretariat:
   • Designates a Secretariat member to shepherd the Recommendation through the process (typically the Secretariat liaison to the relevant WG).
   • Gives the document a name and puts it into a special repository for Recommendation drafts.
   • Sets the document status to draft
   • Notifies the OA/OAB about the new draft Recommendation. 
3. Member Comment: After the two week initial review, the Secretariat
   • Posts the Recommendation on the RDA forum along with a request for comment to the entire RDA membership.
   • Members are given four weeks for review, comment,and discussion, including a discussion of whether the Recommendation meets the criteria of a Recommendation. If there is a major discussion about the Recommendation the chairs may request that the Secretariat extend the comment period.
4. Finalization for Council: At the end of the comment period, the Chairs and TAB agree on further procedure.
   • In the case of severe comments on the content of the Recommendation, the draft is returned to the WG for further discussion. If the WG has expired, it is extended up to three months as agreed with the TAB. The WG chairs can decide at any moment to state rough consensus again and the procedure starts with point 1 again.
   • In case of minor comments on the content, TAB and chairs may agree on minor corrections.
   • After having improved the document the Secretariat will send the Recommendation to the Council for approval.
5. Council Review: The Council has two weeks to evaluate the submitted Recommendation on political issues and to give comments.
   • In case of severe comments the TAB and chairs need to decide in collaboration what the further procedure will be. The proposal could be returned to the WG to start with point 1.  If the WG has expired, it may be extended up to three months as agreed with the TAB.
   • In case of minor comments on the content, TAB and chairs may agree on minor corrections.
   • After having improved the document the Secretariat will send the Recommendation to the Council for final approval.
6. Approval: Upon approval, the Secretariat
   • ​​Registers a persistent identifier for the Recommendation, including necessary citation information.
   • Creates and attaches appropriate license or waiver for the Recommendation as defined in the RDA Outpus Policy.
   • Publishes the Recommendation on the public RDA Web site.
   • Announces the Recommendation to the membership and appropriate other channels.

Criteria for RDA Recommendations

RDA Recommendations are typically documents, but they may include more complex files such as schemas, ontologies, and data models. Recommendations must:

• Advance the mission of RDA.
• Be approved according to the procedure outlined above.
• Have demonstrated application or users and supportive community consensus.
• Reference appropriate other documents and community practice.
• Be available under the default RDA Creative Commons Attribution Only 4.0 license (CC-BY) or the Creative Commons CC0 1.0 Public Domain Waiver (CC0).
  • RDA seeks for Recommendations to be publicly useable and useful with reasonable credit going to RDA and its members. Given the potential diversity of Recommendations, alternative open licenses or waivers may be more appropriate if approved by the TAB and Council. The proposing Group must include a detailed justification for using a license or waiver other than the default that shows how the alternative better advances the mission, principles, or goals of RDA.
• Have a controlled versioning method and be versioned.
• Provide sufficient citation information within the Recommendation, including:
  • Enough information to register a Persistent Identifier [With CrossRef, DataCite, other?].
  • Appropriate, defined authorship. While Groups can be listed as authors, individuals should be specified as appropriate. All members of a Group should be given the opportunity to be listed as supporting or endorsing authors.
  • Research Data Alliance listed as "publisher" or equivalent.
• Require ongoing maintenance and versioning, i.e. they are not static or must be periodically reviewed or generally need to be kept current to be persistently useful.
• Be simple in form and be readily preserved and shared. The intent of this criterion is to allow Recommendations more complex or esoteric than basic documents but not to require significant user support or major attention to long-term operational considerations like changes in computer operating systems, configurations, libraries, etc.
• Include a short maintenance and retirement plan that identifies:
  • who will ensure the Recommendation is kept current. A demonstrated community interested in the Recommendation is especially desirable. Possibilities for a maintenance group could include an RDA IG, an affiliate organisation, an ad hoc group that (re)convenes on a periodic schedule (e.g. annually), a special WG, etc.
  • how the Recommendation would be superseded or retired, if appropriate.
  • suggestions on the status of the Recommendation if RDA ceases to exist.