Contribute a useful scientific resource

Choose your starting point

Dataset, task and benchmark describe what you are contributing. An executable RSI study is an optional addition.

A source suggestion can become an external-resource listing after its metadata, access route and scientific relevance are reviewed. A complete checkable package follows the data-validation route. Listings state exactly what was checked.

Your dataset can stay with its current host

Link a version on Zenodo, Hugging Face, GitHub or an institutional repository. RSI4Science maintains the catalog, usage guidance and review information. Contributors can keep the full data with its original host; small, permitted examples may be offered as separate downloads.

Provide the dataset landing page and download or access instructions, exact version or commit, license, format and approximate size. A paper link explains the research; reviewers also need a route to the data. For controlled-access resources, link the public application instructions and describe the restrictions.

External-resource listing. Share the source URL, version, access and reuse terms, a representative example and the scientific use it supports. Automated catalog checks validate required metadata and link syntax; maintainers then verify the source, access route and described use. A listing records the review date and evidence. It directs users to the original host, and states whether the underlying data has been checked.

Checked benchmark package. For formal package review, reviewers obtain the agreed version through an authorized route, rerun applicable checks and record the files and scope examined. The current checker reads supported JSON files locally and does not follow URLs. Large or unsupported formats need an agreed check before review. See the current format and limits.

The website form prepares a local draft; there is no general file-upload service. To request review, share public links through the project contact. External-resource review establishes the scope of the listing. Scientific validation of a benchmark package also requires inspecting its records and checking its scoring procedure.

For a checkable package: prepare and validate

The resource example shows the two files: a manifest describing the source and schema, and records containing inputs and targets. Use track: "candidate_resource" for this submission route; it has no RSI experiment contract. The form’s research area and specialty or task keywords belong in the usage card.

• Data checks: fields and types, units, missing values, unique IDs, declared counts, exact duplicate inputs and declared family separation.
• Source checks: required version, citation, access and reuse declarations. People verify their authenticity.
• Coverage: check every development/selection record in the declared package. Samples receive a sample-only result; reviewers verify the scope against the original source.

The current validator supports scalar JSON fields with reference targets. Native arrays, images, nested structures, simulators and unlabeled sources first need an agreed representation. Keep the original data intact and start with a source suggestion.

For an ordinary resource with no reserved evaluation set, declare protected_evaluation: {"availability":"none"}. Reviewers confirm that scope. If protected records and answers do exist, document their actual custody and keep them outside the submitted files.

Run the browser check or download the offline checker. Correct reported issues and save the resulting report.

What human reviewers check

For an external-resource listing, reviewers check the public source, version, access terms, representative example and stated use. Its entry records this limited scope. For a benchmark package, share the report, exact version, usage guide and public source links with the maintainers. Agree a permitted route before transferring restricted data. Reviewers independently rerun the checks and assess:

1. Scientific meaning. Authentic sources, valid labels and units, the question being tested and the limits of the checker.
2. Feedback and evaluation. What users can learn from an outcome, whether suggested diagnostic comparisons are justified, and which related cases must stay together. Missing independent cases remain a documented limitation.
3. Reproducible use. A second person follows the guide from a clean download or approved access route and obtains the expected output.
4. Release conditions. Reuse permissions, private/public boundaries, source citations and the exact files that may be distributed.

Scientific and engineering review are recorded separately; authors cannot approve their own package alone. The review record binds the decision to the checked version and file hashes. A failed check or unresolved review issue needs a revision before release. No review deadline is currently promised.

An approved resource becomes usable by others

A maintainer approves a listing with its scientific purpose, documented scope, original sources, versioned access route, usage guide and permitted downloads. Each resource keeps its access and reuse terms. A new version requires a fresh check and review of the changes.

Sources and people

Contributors may create datasets, curate published research, prepare checks or adapt resources for reuse. You can contribute work based on your own research or someone else’s, with clear sources and appropriate reuse permission.

Each dataset page lists its contributors alongside a separate source citation, with a paper link when available. Institutions are optional. Teams can include several people across institutions, in their agreed order. The homepage map links to these dataset pages. Public profiles are optional; we confirm display permission before publication. Contact us to update or remove a profile.

Dataset review and release status are recorded separately on the resource page. Source and reuse notes.

Practical questions