---
name: solo-open-dataset
description: Publish a dataset openly with a citable DOI — one GitHub repo per dataset, CITATION.cff, CC BY 4.0, Zenodo minting a DOI for every GitHub release, large media on Hugging Face. Use when the user says "выложи датасет", "открытый датасет", "нужен DOI", "Zenodo", "научный датасет", "publish this data", "make it citable", or a project collects data meant for researchers. Do NOT use for app/store releases (use /ios-release) or for a private backup.
license: MIT
metadata:
  author: fortunto2
  version: "1.0.0"
  openclaw:
    emoji: "🗃️"
---

# open-dataset — data people can cite, reuse and trust

A dataset is useful to science when someone can find it, cite one exact version of it, and
know what they are allowed to do with it. The cheapest stack that gives all three: a public
GitHub repo per dataset, Zenodo archiving each release with a DOI, CC BY 4.0. No Zenodo token
is needed; the GitHub integration does it.

## Workflow

1. **Decide what may go out.** Publish what you *made*: measurements you took, transcriptions,
   an index you built, contributions people sent with consent. Individual facts are not
   protected; someone else's database as a whole is (the maker's database right). A mirror of
   another archive's scans or catalogue stays private; a catalogue copied from an inventory is
   a borderline case that needs an explicit decision, not a default.
2. **Strip bearer secrets.** Any id that also works as a credential (a "delete my data" token,
   an API key, a device id that unlocks something) never leaves the server. Replace it with a
   keyed one-way code (`blake2b(id, key=salt, digest_size=8)`), the salt kept outside the
   repo and constant across releases, so one source's rows stay groupable without being
   linkable back. Coarsen what could identify a person (location to 0.1°, timestamps if they
   pin a home).
3. **One repo per dataset**, public, named for the data (`<project>-<what>-data`):
   - `README.md`: what it is, how it was made, every column, caveats, how to cite
   - `CITATION.cff` (`type: dataset`, `license: CC-BY-4.0`, authors, keywords, abstract):
     Zenodo reads its metadata from this
   - `LICENSE`: CC BY 4.0 with the exact credit line you want
   - the tables (CSV, or Parquet past ~100 MB), regenerated by a script kept in the source
     project, never edited by hand
4. **Switch on Zenodo once per repo**: zenodo.org/account/settings/github → toggle the repo.
   Verify instead of trusting the toggle:
   ```bash
   gh api repos/<owner>/<repo>/hooks --jq '.[] | {url: .config.url, events, active}'
   ```
   A `zenodo.org/api/hooks/receivers/github/...` hook with `events: ["release"]` and
   `active: true` means every release will be archived.
5. **Release = version = DOI.** `gh release create v<version> --notes-file README.md`. Zenodo
   mints a DOI per version plus a concept DOI that always points at the latest. Put the
   concept DOI in the README after the first release.
6. **Media go to Hugging Face Datasets** with the same tables (`huggingface_hub`
   `upload_folder`, `repo_type="dataset"`, a dataset card with `license: cc-by-4.0` front
   matter). Reason in Gotchas.
7. **If several datasets belong together**, keep an index repo that lists each one with its
   repo, record count, DOI and versions.

## Gotchas

- **Zenodo archives the repository, not release assets.** A photo zip attached to a GitHub
  release does not reach Zenodo. Put media on Hugging Face (or upload to Zenodo through its
  REST API with a token, if one release must carry them), and keep git for tables, which also
  keeps the repo small.
- **Consent text and licence must agree before the first row is collected.** Contributors
  who agreed to "a dataset" did not agree to CC BY; you cannot re-ask them all later. Say in
  the consent and the privacy policy that copies of an earlier release cannot be recalled,
  and that deleting removes the data from every later release.
- **A deleted contribution must disappear from the next release.** Build each release as a
  full snapshot from the live store, never by appending to the previous one.
- **Test the export on one real row, then delete it.** An export that "works" on an empty
  table has not checked the pseudonym, the joins or the media download.

## Don't

- Don't publish a raw dump of someone else's database, even if every field is a fact.
- Don't publish the real contributor id "because it is random": random is not the point,
  what it unlocks is.
- Don't attach the media to the GitHub release and assume Zenodo kept them.
- Don't hand-edit the published CSVs; regenerate them, or the next release silently reverts
  the fix.