One of the top pieces of feedback we got from NDRH2026 was that it would be helpful to have demonstrations of how to open, read, visualize and analyze specific datasets. That's exactly what the dandi notebooks repo provides. I think the best way to address this feedback is to improve the discoverability of those notebooks (and to improve their coverage of datasets, but that's a separable task). The DANDI notebook collection at notebooks.dandiarchive.org now covers 34 dandisets with 63 notebooks, each runnable with one click in Google Colab or locally as a verified container image (background: https://about.dandiarchive.org/blog/2026/08/20/dandi-notebooks/). Right now nothing on a dandiset's landing page tells a visitor those notebooks exist. This proposes a small panel that does.
Data Source
The notebook site publishes a static, machine-readable index at https://notebooks.dandiarchive.org/notebooks.json (dandi/example-notebooks#203). It is keyed by dandiset ID and regenerated automatically whenever the collection changes:
{
"schema_version": 1,
"index_url": "https://notebooks.dandiarchive.org/",
"docker_help_url": "https://notebooks.dandiarchive.org/docker-help.html",
"dandisets": {
"001550": {
"index_url": "https://notebooks.dandiarchive.org/#dandiset-001550",
"notebooks": [
{
"path": "001550/PaganLab/01_behavior_demo.ipynb",
"github_url": "https://github.com/dandi/example-notebooks/blob/master/001550/PaganLab/01_behavior_demo.ipynb",
"colab_url": "https://colab.research.google.com/github/dandi/example-notebooks/blob/master/001550/PaganLab/01_behavior_demo.ipynb",
"docker_image": "ghcr.io/dandi/example-notebooks/001550-paganlab",
"docker_command": "docker run --rm -p 127.0.0.1:8888:8888 ghcr.io/dandi/example-notebooks/001550-paganlab:latest"
}
]
}
}
}Fields are null when a path does not apply (a notebook without a published image has docker_image: null). The shape is versioned and will only change additively; we will treat it as a contract with the archive.
Proposed Behavior
On the dandiset landing page, fetch notebooks.json once (it is static on GitHub Pages, cache-friendly, and small), and if the current dandiset ID is present, render an "Example notebooks" section listing each notebook with an "Open in Colab" link and, when available, a copy-to-clipboard docker command with a link to the help page. If the ID is absent or the fetch fails, render nothing. No backend involvement and no per-dandiset metadata.
Why This Route
The alternative is a relatedResource entry in each dandiset's metadata, which is the right thing for citable cross-references (and we intend to add those for notebooks that reproduce published figures once they carry DOIs, see dandi/example-notebooks#202), but it requires editing every dandiset's metadata by hand and goes stale as notebooks are added. Reading the index makes discoverability automatic and always current, and the two approaches complement each other.
I am happy to help with the frontend change if that is useful.
One of the top pieces of feedback we got from NDRH2026 was that it would be helpful to have demonstrations of how to open, read, visualize and analyze specific datasets. That's exactly what the dandi notebooks repo provides. I think the best way to address this feedback is to improve the discoverability of those notebooks (and to improve their coverage of datasets, but that's a separable task). The DANDI notebook collection at notebooks.dandiarchive.org now covers 34 dandisets with 63 notebooks, each runnable with one click in Google Colab or locally as a verified container image (background: https://about.dandiarchive.org/blog/2026/08/20/dandi-notebooks/). Right now nothing on a dandiset's landing page tells a visitor those notebooks exist. This proposes a small panel that does.
Data Source
The notebook site publishes a static, machine-readable index at
https://notebooks.dandiarchive.org/notebooks.json(dandi/example-notebooks#203). It is keyed by dandiset ID and regenerated automatically whenever the collection changes:{ "schema_version": 1, "index_url": "https://notebooks.dandiarchive.org/", "docker_help_url": "https://notebooks.dandiarchive.org/docker-help.html", "dandisets": { "001550": { "index_url": "https://notebooks.dandiarchive.org/#dandiset-001550", "notebooks": [ { "path": "001550/PaganLab/01_behavior_demo.ipynb", "github_url": "https://github.com/dandi/example-notebooks/blob/master/001550/PaganLab/01_behavior_demo.ipynb", "colab_url": "https://colab.research.google.com/github/dandi/example-notebooks/blob/master/001550/PaganLab/01_behavior_demo.ipynb", "docker_image": "ghcr.io/dandi/example-notebooks/001550-paganlab", "docker_command": "docker run --rm -p 127.0.0.1:8888:8888 ghcr.io/dandi/example-notebooks/001550-paganlab:latest" } ] } } }Fields are null when a path does not apply (a notebook without a published image has
docker_image: null). The shape is versioned and will only change additively; we will treat it as a contract with the archive.Proposed Behavior
On the dandiset landing page, fetch
notebooks.jsononce (it is static on GitHub Pages, cache-friendly, and small), and if the current dandiset ID is present, render an "Example notebooks" section listing each notebook with an "Open in Colab" link and, when available, a copy-to-clipboard docker command with a link to the help page. If the ID is absent or the fetch fails, render nothing. No backend involvement and no per-dandiset metadata.Why This Route
The alternative is a
relatedResourceentry in each dandiset's metadata, which is the right thing for citable cross-references (and we intend to add those for notebooks that reproduce published figures once they carry DOIs, see dandi/example-notebooks#202), but it requires editing every dandiset's metadata by hand and goes stale as notebooks are added. Reading the index makes discoverability automatic and always current, and the two approaches complement each other.I am happy to help with the frontend change if that is useful.