FAIR Data Clinic Toolkit: research-object preparation, README generation, and a future Dataverse deposit workflow
Richard Dennis
Hello Dataverse community,
I would like to share a project I have been developing and invite feedback from the Dataverse community.
The TU/e FAIR Data Clinic Toolkit is a researcher-centered tool designed to help researchers examine, improve, and prepare a research object before repository deposit.
Rather than calculating a FAIR score or attempting to certify that a dataset is FAIR, the toolkit focuses on a practical question:
Is this research object sufficiently organized, documented, interpretable, and reusable for another researcher, and what should be improved before it is deposited?
The toolkit examines areas such as:
README and dataset-level documentation;
organization and structure of files;
data dictionaries and variable descriptions;
units, value codes, and missing-value conventions;
file formats and basic technical usability;
methods and provenance information;
software and computational context where relevant;
licensing and reuse information;
consistency between documentation, data files, metadata, and other components of the research object.
The goal is not simply to identify problems. The researcher should receive practical guidance about what needs attention, what they can improve themselves, and when an issue requires professional review.
I have noticed considerable interest within the Dataverse community in README generation and in improving dataset-level documentation. This aligns closely with the direction of the toolkit.
I have therefore been examining work such as the Borealis README guidance, the Scholars Portal README Generator prototype, data-dictionary guidance, and related approaches. I intend to incorporate README generation and improvement directly into the toolkit.
The intended workflow is not simply:
check the README → report that something is missing
but rather:
assess the research object → identify documentation gaps → help the researcher improve or generate the README and related documentation → reassess the package → prepare it for deposit
I think this is particularly important because repository metadata alone may not provide everything another researcher needs to understand and reuse the deposited files. README files, data dictionaries, methods information, software information, and documented relationships between files can provide essential context around the research object.
Dataverse is also part of the planned repository workflow itself.
The current public release does not yet submit directly to Dataverse. A planned development step is to add Dataverse-specific preparation and ultimately support the transfer of the prepared research object and relevant metadata into Dataverse.
The intended future workflow is therefore approximately:
Research object → FAIR Data Clinic assessment → researcher improvements → README/documentation generation → reassessment → Dataverse preparation → transfer of the prepared research object and relevant metadata into Dataverse
Dataverse would remain responsible for the repository environment and final repository functions. The toolkit would focus on helping the researcher arrive at Dataverse with a substantially better-prepared research object and, ultimately, transferring that object and the relevant metadata into the repository.
This is why I am particularly interested in input from the Dataverse community now, while the repository-facing part of the toolkit is still being developed.
I would be very interested in feedback from Dataverse repository managers, developers, research data professionals, and researchers, particularly around questions such as:
What documentation problems do you most commonly encounter when datasets reach Dataverse?
What should a useful README generator for Dataverse-bound research objects help researchers document?
Which information already held in Dataverse should be reused rather than requested from the researcher again?
Which information should ideally be generated or improved before the research object is transferred to Dataverse?
Which checks would be most valuable before deposit?
What would make a FAIR Data Clinic to Dataverse transfer workflow genuinely useful rather than simply adding another step?
Are there existing Dataverse tools, APIs, external tools, or workflows that you think I should examine before developing the Dataverse integration?
The latest public version of the toolkit is available on Zenodo:
https://zenodo.org/records/21949245
The toolkit remains under active development. I am sharing it here because I would like the Dataverse community to help inform the README, documentation, and repository integration aspects of the development, rather than designing those elements in isolation.
Comments, criticism, examples of existing workflows, and suggestions are very welcome.
Best regards,
Richard Dennis
Data Steward, Department of Mechanical Engineering
Eindhoven University of Technology (TU/e)
Philip Durbin
--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/b573a204-6611-4437-8984-e9f35fcda8d5n%40googlegroups.com.
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin
Richard Dennis
Hi Phil,
Thank you very much for taking the time to look at the toolkit and for opening the GitHub issue.
You are correct about the hard-coded Data Steward list. That should not be part of the institution-neutral version of the platform. The toolkit originally grew out of a TU/e-specific implementation, and I am now separating the core assessment and preparation functionality from institution-specific configuration. Named support personnel should therefore be configurable by an institution rather than embedded in the core application. I will make sure the issue is incorporated into that work.
I would also be very interested in presenting the project during a Dataverse community call sometime soon in the future. I think it would be useful to present both what the platform currently does and its development direction, while being very clear about what is implemented today versus what is planned.
The Dataverse integration is still a future development stage. My current roadmap is to complete the repository-neutral core first, followed by repository adapters, including Dataverse. The intention is not simply to upload files to Dataverse, but to preserve the assessment and preparation evidence and then use Dataverse metadata and APIs for repository-specific preparation and, where appropriate, post-transfer verification.
Once that integration is implemented and tested, I would definitely like to work with the community to have it listed as a Dataverse integration.
Thank you again for looking at the project and for the feedback. This is exactly the kind of external use and review that is useful as the platform develops.
Best regards,
Richard
Barbosa, Sonia
ᐧTo view this discussion visit https://groups.google.com/d/msgid/dataverse-community/a4c1c586-4192-4a0f-a245-c7ea4b919932n%40googlegroups.com.
Associate Director of Dataverse Support, Data Curation, and the Murray Archive.
The Dataverse Project
Join our Dataverse Community! https://groups.google.com/forum/#!forum/dataverse-community
Richard Dennis
Dear Sonia,
Thank you for reaching out. I would be very interested in speaking with you, particularly given your work with Dataverse support and data curation and the packaging-tool pilot you mentioned.
The project I have been developing originated as the TU/e FAIR Data Clinic Toolkit and is now evolving toward a more general platform that we are calling RORA — Research Object Readiness and Assessment Platform.
The central purpose is to help researchers assess and improve a research object before repository deposit. Rather than producing a FAIR score or certification, RORA examines the evidence associated with a research object—its structure, documentation, metadata, technical integrity, computational reuse information, provenance, licensing and related preparation elements—and identifies concrete readiness issues and remediation actions.
One of the architectural decisions I have been quite deliberate about is separating the repository-neutral assessment core from repository-specific behavior. The core determines what can be established from the research object and its evidence. Repository adapters can then handle deposit requirements, metadata mappings, package transfers, and repository-specific validation without making those requirements universal assessment criteria.
We are also beginning to incorporate bounded technical diagnostics as researcher-assistance functions. For example, Markdown documentation can be checked locally for structural and accessibility issues, while public-link checking is optional and consent-based. Importantly, those diagnostics remain separate from the governed assessment logic—they assist remediation but do not determine readiness.
Dataverse is explicitly on the development roadmap, but the Dataverse adapter has not yet been implemented. I want to be precise about that distinction. The planned work is intended to examine how RORA preparation outputs can map into Dataverse metadata, files, validation, packaging, and deposit workflows while preserving the separation between repository-neutral assessment and Dataverse-specific requirements.
Your packaging-tool pilot is therefore particularly interesting to me. I would very much like to understand which tool you are working with, what problem it is intended to solve, and what you are learning from the pilot. I suspect there could be useful points of comparison regarding package structure, metadata reuse, validation, researcher guidance, repository handoff, automation boundaries, and the areas where professional curation or review remains necessary.
I would be happy to show you the current RORA work and discuss the architecture and roadmap. I would also appreciate the opportunity to learn more about your work and explore whether there are useful areas for comparison or collaboration.
Best regards,
Richard Dennis
Data Steward, Department of Mechanical Engineering
Eindhoven University of Technology (TU/e)
Philip Durbin
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/13912443-76e5-4d47-acf5-8501155e54f5n%40googlegroups.com.