DataverseUA deposit checklist
Use this checklist before submitting or publishing a research dataset in DataverseUA. It helps verify that the correct repository collection has been selected, required metadata have been completed, files and documentation are ready, and access and reuse conditions are stated consistently.
The checklist complements the FAIR package pre-check. It focuses on the repository record and the correspondence between the DataverseUA metadata form and the deposited data package.
Resource information
Resource type
Repository deposit checklist
Intended users
Dataset authors, authorised depositors, data curators and data stewards
Recommended use
Preparation, review and final verification of a DataverseUA dataset record
Status
Recommended repository deposit checklist of the Competence Center
Download the checklist
Use the XLSX version to record the deposit status, evidence, unresolved issues and corrective actions. The DOCX version is suitable for review with dataset authors before repository submission.
Available formats
What does the checklist cover?
The checklist reviews the complete repository deposit process from selecting the appropriate collection to verifying the final dataset landing page.
Deposit authority and collection
Responsible depositor, author approval, appropriate Dataverse collection, dataset scope and institutional responsibility.
Repository metadata
Title, authors, contacts, description, subject, keywords, identifiers, funding and related research outputs.
Files and documentation
Data files, README, manifest, metadata, scripts, provenance, formats, file descriptions and technical validation.
Access, licence and publication
File restrictions, terms of access, licence, rights holder, version, repository review and final publication checks.
Minimum deposit package
At minimum, prepare the principal data files, a current README, a structured file inventory or manifest, a complete draft repository metadata record, and confirmed access and reuse conditions.
Add scripts, software-environment information, provenance, configuration files, data dictionaries and quality-control evidence whenever they are required to interpret or reproduce the dataset.
Detailed DataverseUA deposit checklist
Review every criterion against the actual DataverseUA draft, deposited files and supporting documentation. Complete all fields marked as required in the repository form.
| Area | Deposit criterion | Expected evidence |
|---|---|---|
| Authority and deposit scope | The depositor is authorised to submit the dataset. | Author, project or institutional approval |
| The persons responsible for the scientific content are identified. | Creators, contributors and contact person | |
| The dataset is ready for repository deposit and represents a defined research output. | Approved title, scope and package version | |
| The appropriate DataverseUA collection has been selected. | Institutional, project or thematic collection | |
| The dataset is not an unintended duplicate of an existing record. | Repository search and version review | |
| Responsibility for future updates and versioning has been assigned. | Named dataset owner or responsible group | |
| Dataset identification | The title clearly identifies the dataset and its scientific content. | Repository title field |
| The title is consistent with the README and metadata files. | Cross-record comparison | |
| The resource is described as a dataset rather than as an article or project. | Repository record and description | |
| The dataset version has been defined. | Version in README and repository metadata | |
| The publication year or relevant date is correct. | Date fields in the draft record | |
| The dataset language has been identified where applicable. | Language metadata | |
| The existing identifier shown by DataverseUA is used consistently. | Identifier displayed in the draft or published record | |
| No DOI or persistent identifier has been invented or entered manually as the dataset identifier. | Repository-generated identifier only | |
| Authors, contributors and contacts | All principal dataset creators are listed. | Author or creator fields |
| Names use one consistent form and order. | Repository–README–publication comparison | |
| ORCID identifiers are included where available. | Valid ORCID values | |
| Institutional affiliations are complete and current. | Affiliation fields | |
| Organisation identifiers are included where supported and available. | ROR or another persistent identifier | |
| Contributors are distinguished from creators. | Contributor names and roles | |
| A current contact person is identified. | Dataset contact field | |
| The contact email is institutional or otherwise suitable for long-term communication. | Verified contact email | |
| Description and discovery | The description explains the content, purpose and scope of the dataset. | Description or abstract field |
| The description states how the data were created or collected. | Methods summary | |
| The principal data types and processing levels are identified. | Raw, processed, derived or final data statement | |
| The appropriate subject or scientific discipline has been selected. | Subject field | |
| Keywords are specific, consistent and useful for discovery. | Keyword fields | |
| Specialist terms and abbreviations are explained. | Description or README | |
| Temporal, spatial or material coverage is recorded when relevant. | Coverage metadata | |
| The repository description is understandable without opening every file. | Complete landing-page metadata | |
| Funding and related outputs | The relevant project or funding source has been identified. | Funding reference |
| Grant or award numbers are entered correctly where applicable. | Award number | |
| Related publications are linked using persistent identifiers where available. | Article DOI | |
| Related software is identified. | Software DOI, repository URL or citation | |
| Related datasets and previous versions are linked. | Related identifiers | |
| The relationship type is stated correctly where supported. | IsSupplementTo, IsDerivedFrom or another appropriate relation | |
| Links resolve to the intended research outputs. | Successful link check | |
| Files and package organisation | All principal files have been uploaded. | DataverseUA file list |
| The uploaded files correspond to the reviewed package version. | Package version and file comparison | |
| File names are meaningful and consistent. | Repository file list | |
| Temporary, duplicate and unintended files have been removed. | Final file review | |
| Files are uploaded individually where this improves discovery and reuse. | Repository file structure | |
| Archives are used only when grouping is technically or scientifically justified. | Documented reason for ZIP or another archive | |
| File formats correspond to the extensions and descriptions. | Technical file validation | |
| Large or specialist files have sufficient format and software information. | README and file descriptions | |
| Principal files can be opened or validated before deposit. | File-opening or syntax-validation result | |
| README, manifest and supporting records | A current README is included. | README.md or equivalent document |
| The README explains the package contents and file structure. | README contents | |
| A manifest or structured file inventory is included where required. | manifest.csv, XLSX or JSON |
|
| Manifest paths and file names match the deposited files. | Successful path comparison | |
| Scripts, configuration and environment files are included when needed for reuse. | Supporting files | |
| Provenance or workflow information is included when relevant. | Provenance or workflow record | |
| Documentation does not refer to files that are absent from the deposit. | README–manifest–repository comparison | |
| Access and restrictions | The intended access status has been defined for the dataset and files. | Open or restricted file settings |
| Open files do not contain confidential, personal or restricted information. | Content and sensitivity review | |
| Restricted files are clearly identified. | File restriction settings | |
| The reason for restriction is documented. | Terms of access or access note | |
| The procedure for requesting access is understandable. | Access-request information | |
| Embargo dates and conditions are accurate where applicable. | Embargo settings | |
| Public metadata do not disclose restricted or sensitive information. | Metadata sensitivity review | |
| File-level restrictions are consistent with the description and README. | Cross-record comparison | |
| Licence and rights | The rights holder has been identified. | Rights statement or author confirmation |
| The depositor has authority to publish the files. | Author, project or institutional approval | |
| A licence or reuse statement has been selected. | Repository licence field | |
| The licence is appropriate for the deposited content. | Licence review | |
| Third-party files are not covered by an incompatible licence. | Third-party rights review | |
| The licence is represented consistently in the README and repository record. | Cross-record comparison | |
| Restrictions are not incorrectly presented as an open licence. | Access–licence consistency check | |
| Final draft review | The dataset landing page has been previewed. | Draft-page review |
| Title, creators, description and subject display correctly. | Repository preview | |
| File names, sizes, formats and restrictions display correctly. | File-list preview | |
| Links, identifiers and related publications are correct. | Link and identifier check | |
| The draft contains no placeholder or example values. | Metadata review | |
| The final record is consistent with the approved data package. | Repository–package comparison | |
| The responsible author or reviewer has approved publication. | Reviewer name and approval date | |
| After publication | The published landing page opens correctly. | Public record check |
| The identifier displayed by DataverseUA resolves to the dataset. | Identifier resolution test | |
| Public files can be downloaded and restricted files remain protected. | Access test | |
| The recommended citation is correct. | Repository citation | |
| The publication URL and identifier are communicated to the authors. | Deposit completion record |
How to record the result
Record the status, evidence and required corrective action for every deposit criterion.
Yes
The criterion is satisfied and verified in the repository draft.
Partly
The information is present but requires correction or completion.
No
The criterion has not been satisfied.
Not applicable
The criterion does not apply to this deposit.
Needs clarification
Repository, legal or methodological advice is required.
How to use the checklist
1. Prepare
Complete the FAIR package pre-check and freeze the deposit package version.
2. Create
Create the DataverseUA draft in the appropriate collection.
3. Complete
Enter the metadata, upload files and configure access and licence.
4. Compare
Compare the draft landing page with the approved data package.
5. Verify
Review the published record, identifier, files and citation.
Issues that should block publication
Do not publish the dataset until the following critical issues have been resolved.
Unverified authority
The depositor does not have confirmed authority to publish the dataset or included files.
Sensitive content risk
Personal, confidential, restricted or security-sensitive information has not been adequately reviewed.
Incomplete deposit
Principal files, metadata, README or access information are absent or materially incomplete.
Contradictory conditions
Licence, access restrictions, file settings or metadata contain conflicting information.
Record the completed deposit
Record the dataset title, DataverseUA collection, depositor, package version, review date, reviewer, publication date, landing page and persistent identifier shown by the repository.
The deposit record should also identify any restricted files, unresolved follow-up actions and the person responsible for future versions.
Important notes
- Complete all metadata fields marked as required in the actual DataverseUA deposit form.
- Use the identifier displayed by DataverseUA; do not invent or manually construct a dataset DOI.
- Keep the dataset title, creator names, version, licence and access conditions consistent across the repository, README and metadata files.
- Review individual file restrictions rather than assuming one access setting applies automatically to every file.
- Do not upload passwords, API keys, authentication tokens, confidential configuration files or unintended personal data.
- Avoid depositing only a single archive when individual files can be uploaded and described more usefully.
- Preview the landing page and file list before publication.
- Recheck the public record and identifier after publication.
- Any later change to deposited files or metadata should follow the repository’s versioning and update procedure.